Committed my metrics work and some optimizations to my
fork.
The metrics take the form of 3 overlays that are toggled through with F4. The first screen shows the running means for the top 10 marked activites:
The second screen shows highest recent spikes, decaying over time.
With the spikes screen I noticed that the spiking seemed kind of random, so I figured that other threads were interrupting at various times and being charged to whatever activity was running, so I added a view of threads run during the current frame. This probably needs to be improved so it is easier to see what is going on, and some time cost information would be nice too.
Optimisations
I've made two changes in my fork that have alleviated the stuttering issue I was encountering somewhat:
* Set thread priorities. With the main thread set to max priority and all other threads set to minimum the frame rate was smoother for me, probably because background threads were more likely to be processed during Display.sync().
* 16 threads were being started each frame to update chunk rigid bodies, most of which would do little to no work as they'ld stop during three early checks - which also prevented them appearing in the active threads debug display. I changed it so the threads would only be created after those checks.
One thing that may be worth considering in the future is to switch from jbullet to native bullet. This will allow taking advantage of GPU acceleration when it comes in bullet 3.0.