Significant drop in frame rate on very first collision?

[Spankenstein]

I have noticed that there is a significant drop in the frame rate when an entity (Box) collides with the environment bounds (Triangle).

I have attached a small demo (with source) that highlights this problem. [WASD keys to move. Mouse to look]

What is the cause of this?

EDIT: The effect is more pronounced when in debug mode (F5) and not running the .exe directly.

[Norbo]

I have noticed that there is a significant drop in the frame rate when an entity (Box) collides with the environment bounds (Triangle).

I see one momentary spike on impact but no persistent post-impact slowdown; this post assumes the spike is the effect in question.

What is the cause of this?

I would guess lazy initialization and/or JIT compilation. There's quite a bit of stuff that doesn't technically need to exist yet as far as the program is concerned until an impact occurs.

If it's caused by lazy initialization of a bunch of resources, you could try forcing initialization earlier. Possible culprits include the NarrowPhaseHelper factories.

If it's caused by the JIT, then using NGen to precompile or forcing it to prepare all of the assemblies upfront during load would help. The same sort of approach used to prepare all the types in an assembly could force the otherwise lazy initialization, too. Regardless of where exactly the time is being spent, force-loading every assembly and force-preparing every method in those assemblies seems to eliminate the problem.

Here's some more information: http://blog.liranchen.com/2010/08/forci ... ntime.html

EDIT: The effect is more pronounced when in debug mode (F5) and not running the .exe directly.

Running in debug mode imposes significant overhead; be careful when using it for performance analysis.

[Spankenstein]

If it's caused by lazy initialization of a bunch of resources, you could try forcing initialization earlier.

How would you recommend doing this? Is there anyway to force two objects to collide during load time and initialize the resources (LoadContent)? For example, can I force one update (time step) to be performed by the engine during this method?

[Norbo]

Check out the linked blog post; forcing the JIT/initialization isn't as complicated as it sounds. It's probably easier than trying to perform a guess-initialization or simulation warmup.

[Spankenstein]

I looked at the link. It seems very simple to implement but shouldn't really be necessary outside of debugging.

However, the spike is still there due to the lazy initialisation when not debugging though, just not as pronounced.

[Norbo]

I looked at the link. It seems very simple to implement but shouldn't really be necessary outside of debugging.

However, the spike is still there due to the lazy initialisation when not debugging though, just not as pronounced.

Did you try implementing the JIT forcing? The problem went away completely when I tested it; just call the force-prepare on each force-loaded assembly. It's a perfectly valid solution that's quite a bit easier than trying to guess which part needs to be initialized.

[Spankenstein]

Did you try implementing the JIT forcing?

Yes and it works but I was unsure how safe it would be outside of debugging on Windows. Running on XBOX for example.

[Norbo]

I know of no safety issues with it on Windows. Not all of the reflection abilities are available on the Xbox360, of course, but there should exist some workarounds. For example, RuntimeHelpers.RunClassConstructor exists in the CF and can be used to accomplish a similar goal (try running it on the NarrowPhaseHelper, it should mostly eliminate the issue). I have not tested this on the Xbox360 itself, so maybe there's some issue, but I don't know of any. If it fails, there's always more options to fall back on

[Spankenstein]

Cool, thank you for clearing that up.

Could you possibly explain how to avoid certain classes in the assembly?

There is a problem stated on the website:

(Remark: it should be noted that calling PrepareMethod may trigger the static constructor of the destination type, that is, if it has one).

This causes issues with a small number of my classes.

I currently have the following in the Initialise method:

Code: Select all

            JITCompilation.PreJITMethods(System.Reflection.Assembly.GetExecutingAssembly());
            JITCompilation.ForceLoadAll(System.Reflection.Assembly.GetExecutingAssembly());

It works with the small project I uploaded but not with my main one, which I have just begun testing.

After testing further with the smaller project it might have been the placebo effect but I don't think the above code has solved the issue. Therefore I have done something incorrectly!

[Norbo]

The unmodified ForceLoadAll method from that article does not call PreJITMethods. So, this code:

Code: Select all

            JITCompilation.PreJITMethods(System.Reflection.Assembly.GetExecutingAssembly());
            JITCompilation.ForceLoadAll(System.Reflection.Assembly.GetExecutingAssembly());

JITs the current assembly, and loads the rest. Since BEPUphysics assembly is the one with the hefty on-collision JIT/initialization cost, prejitting the currently executing assembly doesn't help much. Calling the preJIT from within the ForceLoadAll method will help with this.

Avoiding certain classes could by done by checking the type in the loop. However, you can also just do something like RuntimeHelpers.RunClassConstructor(typeof(NarrowPhaseHelper).TypeHandle) to force that one particular class to run its constructor. NarrowPhaseHelper is the big one for on-collision initialization, anyway.

[Spankenstein]

Just calling the following fixes the problem:

Code: Select all

JITCompilation.PreJITMethods(System.Reflection.Assembly.LoadFrom("BEPUphysics.dll"));

It doesn't appear to require anything else?!

Calling the preJIT from within the ForceLoadAll method will help with this.

Can you please post what code you used? I'm curious as to how you handled this.

I'm also calling the method in the Initialize method, I presume this makes no difference over calling it in the LoadContent method?

[Norbo]

It doesn't appear to require anything else?!

Since the primary source of the on-collision spike is due to lazy initialization of the BEPUphysics assembly, initializing only the BEPUphysics assembly should indeed get rid of it. In fact, using the RunClassConstructor method on only the NarrowPhaseHelper can pretty much eliminate the problem alone too, since the NarrowPhaseHelper is the biggest initialization job.

Can you please post what code you used? I'm curious as to how you handled this.

I've since deleted it, but all it did was call the preJIT method on each assembly handed into the ForceLoadAll method. This is more than is technically needed to solve the on-collision hitch because, as mentioned, most of it's caused by parts of the BEPUphysics assembly being initialized, especially the NarrowPhaseHelper. Prejitting everything could eliminate other minor spikes due to other non-BEPUphysics systems being initialized, though they probably aren't very visible.

I'm also calling the method in the Initialize method, I presume this makes no difference over calling it in the LoadContent method?

Correct, it should not make a difference as far as I know.

[Spankenstein]

Brilliant. Thanks for the info