It is odd that as we look forward to new tools, like the just released RAD Studio 12.2 Athens, we may overlook our own practices which hobble the tools.
The case at hand is configuring a VM for Athens, and for that matter, for Alexandria. I am embarrassed to say that my VM configuration for Alexandria remained as it had been for Rio. I gave it 6GB of RAM, 128MB of display RAM, and 3 cores. The oversignt is in failing to reconsider the core count.
Alexandria gave us LSP, running as a separate process. Athens has beefed up LSP, increasing functionality and performance. And with Athens 12.2, both the compile and LSP may be 64 bit applications, though the IDE remains, for now, 32 bit. So with this new potential, allowing only three cores is quite silly. I had observed some less than wonderful quirks while editing, but failed to make the connection.
Inertia is my only excuse. 99% of my development work is inside a VM, and the settings I use have been stable and consistent for years.
I have now set my VMs for Alexandria and Athens to 8 cores. And if I start using Smart CodeInsight, I may reconsider that count. Who knows? But it has been plain for some years that CPU speed increases were no longer to be hoped. Instead, our performance gains must come from distributing the work. Clearly, that now means more cores, and being open to adding resources as the toolsets evolve.
Now the IDE is more responsive, and I see no more quirks. The build times remind me of the good old days, when builds were very quick indeed. Nice to see that becoming true again. The lesson, however, is that our now so very complex systems may suffer from our own poor choices when we do not fully apprehend our impact on the system.