Hi there!
I have a dynamic CompoundBody constructed from several boxes. Then I'm adding in the space another dynamic body (box or sphere). After that the next space update takes around a second! And then simulation runs smothly. No matter how many another dynamic bodies will be added. I did not dive into bepu source, so I do not undestand what's going on. May be bepu creates some internal data structures. But I think one second is too long. Am I doing something wrong?
[V1] Performance issue
Re: [V1] Performance issue
While there is some initialization and just in time compilation that happens early on in execution, one second is definitely way longer than anything should take unless you're dealing with millions of something.
It's hard to say what would cause that without more information. I'd recommend trying to reproduce it in the BEPUphysicsDemos project so I can take a closer look.
It's hard to say what would cause that without more information. I'd recommend trying to reproduce it in the BEPUphysicsDemos project so I can take a closer look.
Re: [V1] Performance issue
I could reproduce it with demo app. Just take CompoundBodiesDemo and replace constructor code with this one:
On my corei5 first space update takes around 120 ms. On arm device it takes more than half of a second.
Code: Select all
var flat = new Box(Vector3.Zero, 1, 0.03f, 1);
flat.Mass = 1;
List<CompoundShapeEntry> shapes = new List<CompoundShapeEntry>();
shapes.Add(new CompoundShapeEntry(flat.CollisionInformation.Shape, flat.Position));
var composite = new CompoundBody(shapes, 1);
var sphere = new Sphere(new Vector3(0, 0.05f, 0), 0.05f);
sphere.Mass = 0.15f;
Space.ForceUpdater.Gravity = new Vector3(0, -9.8f, 0);
Space.Add(composite);
Space.Add(sphere);
game.Camera.Position = new Vector3(0, 3, 15);
Re: [V1] Performance issue
120ms on the desktop is about right for first frame JIT and initialization. 500ms+ on a slower mobile device makes sense.
If you'd like to push some of that time into the load phase, you can force initialization for all collision pair types during a load phase:
That might shave off a third of the first frame. Forcing a Space.Update() before adding anything can take care of another bit.
Given that the JIT compiles code on demand, you could run a timestep of a representative simulation during load in order to touch all the relevant code.
AOT compilation would help too. You might be able to use ye olde Ngen to get rid of most of the overhead. Mono's AOT toolchain and the upcoming corert runtime could also both be useful here.
If you'd like to push some of that time into the load phase, you can force initialization for all collision pair types during a load phase:
Code: Select all
foreach (var factory in NarrowPhaseHelper.Factories.All)
{
factory.EnsureCount(512);
}
Given that the JIT compiles code on demand, you could run a timestep of a representative simulation during load in order to touch all the relevant code.
AOT compilation would help too. You might be able to use ye olde Ngen to get rid of most of the overhead. Mono's AOT toolchain and the upcoming corert runtime could also both be useful here.
Re: [V1] Performance issue
After some experiments I can see that problem is definitely about JIT. Thank you.