Slow AxisSweep3 startup

[CaptainNemo]

I found that the first and possibly second calls to PerformDiscreteCollisionDetection with AxisSweep3 are very slow if I have ca. > 150-200 collision objects. The time for the first calls seems to explode with the number of objects. I get e.g. times of 7 seconds, while later calls need only 8 milliseconds. The time is apparently burned in the Sort... routines in AxisSweep3.

I built my own broadphase using Opcode, and this doesn't show such a behaviour. But Opcodes Sweep and Prune is generally much faster, I am getting average times of 0.3 milliseconds vs. 8 milliseconds with AxisSweep3.
Perhaps there is some room for improvement.

[Erwin Coumans]

There is definately room for improvements in Bullet, especially in performance optimizations. But 7 seconds startup for ~200 objects sounds like a bug.
The CcdPhysicsDemo has 120 objects, and starts without delay. Usually the broadphase cost is very minor compared to narrowphase.

Do you have a contribution, so we can compare timings? The previous posting has details how to add timings.

Thanks a lot,
Erwin

[CaptainNemo]

Hi Erwin,
I added the profiling code before and after the PerformDiscreteCollisionDetection call, but I couldn't get it to output the time measurement for this call - the .csv file only contains the standard measurements, not mine, and I don't have the time to investigate the cause.
I got the times above by enclosing PerformDiscreteCollisionDetection in timer calls in my own application. Since the times with the Opcode implementation are normal and much better I assume that the cause is not in the way I setup my collision objects. BTW, my times are for 300-500 collision objects, not 150-200 as stated above.

Hope this helps.