For roughly the first 30-40 seconds in my main ‘play game’ state there are a series of severe spikes in the execution time of individual frames. These occur very roughly about 5 seconds apart. Sometimes a spike can cause a frame to be almost 1 second. At about 30 seconds the spikes start to reduce in severity until the game is running with no noticeable issues. (PC is dual core, 3.5Ghz, 64Bit, Java 8, 8 GB RAM).
One severe spike can actually be triggered 100% of the time by clicking on a particular button in the game, but only on the very first click. The spike will not happen again until the game is closed and restarted. I analyzed the code in this button and found nothing that could obviously cause such a big spike.
This made me think that these spikes are due to methods in my code being compiled by the JIT compiler. So using the ASM library I wrote a simple test that parses a JAR containing game class files and writes out the number of bytecode instructions for each method.
The largest method in my main game loop is 2980 instructions while other larger methods are 1891, 1446 and 1037, 1028. I’ve read that Hotspot compiles methods up to about 8000 instructions, so I assume these are being compiled ok.
So I’m wondering if it’s worth the effort of say getting all methods down to a max of 500 instructions or so? I guess that the smaller the methods the faster they can be compiled and therefore a reduction in the severity of spikes? On the other hand, the event handler for the button that causes a spike is only 45 instructions.
I’ve also thought about doing a ‘warmup’ period where I run the full game loop for say 10 seconds but with input disabled / blank display, just to allow the spikes/compilation to occur without annoying the player. Right now, I would actually say that a delay of 10 seconds would be less annoying to the player than having to deal with frame spikes while trying to play the game. Is this a reasonable/common thing to do?
Of course, let me know if you think its not the JIT compiler at all. Thanks.