Conversation
|
Well, I think they were written to get the tiered compilation kick in, so the UI and most important the editor performance would be good right from the start. I do not remember why I used the WarmUp hook for JavaPlatform detection instead of the usual module/main window lifecycle. |
|
@lkishalmi I looked though the repo history and some were written when java 1.4 was hot (no tiered compiler back then). Some also mention class loading and even font loading in the comments. also I just noticed that there might be at least one more which uses the |
Some of the warmup tasks were written in times without concurrent classloading, no class data sharing, no tiered compilation, stop the world GCs, systems with 1-2 cores and mechanical disks. Today, they likely do more harm than good. I tested with disabled warmup tasks the first time usage of: menu entries, auto completion, refactoring, drag and drop, popups etc and could see no difference to before. Everything appeared instantly. The tasks would have taken ~3s total on my system after startup, time the IDE can spend for other things.
|
note to self: could reproduce a small slowdown (probably less than a second, compared to instant opening) when the very first editor tab opens. Might be a reason for keeping one of the editor warmup tasks active after investigating what needs to be still warmed up. |
draft/experiment
Some of the warmup tasks were written in times without concurrent classloading, no class data sharing, no tiered compilation, stop the world GCs, systems with 1-2 cores and mechanical disks.
Today, they likely do more harm than good.
I tested with disabled warmup tasks the first time usage of: menu entries, auto completion, rename refactoring, drag and drop, popups etc and could see no difference to before. Everything appeared instantly.
The tasks would have taken ~3s total on my system after startup, time the IDE can spend for other things.
the following tasks were active (X means now disabled):
remaining tasks are not used for warmup purposes.