Page 1 of 1

[V1] Performance issue

Posted: Sun Aug 12, 2018 5:17 pm
by roro56
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?

Re: [V1] Performance issue

Posted: Sun Aug 12, 2018 8:33 pm
by Norbo
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.

Re: [V1] Performance issue

Posted: Mon Aug 13, 2018 11:55 am
by roro56
I could reproduce it with demo app. Just take CompoundBodiesDemo and replace constructor code with this one:

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);
On my corei5 first space update takes around 120 ms. On arm device it takes more than half of a second.

Re: [V1] Performance issue

Posted: Mon Aug 13, 2018 8:15 pm
by Norbo
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:

Code: Select all

            foreach (var factory in NarrowPhaseHelper.Factories.All)
            {
                factory.EnsureCount(512);
            }
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.

Re: [V1] Performance issue

Posted: Tue Aug 14, 2018 7:37 am
by roro56
After some experiments I can see that problem is definitely about JIT. Thank you.