search

yoshinoToylogic / bulletsharp

Automatically exported from code.google.com/p/bulletsharp
MIT License
0 stars 0 forks source link

Massive StepSimulation() performance leak when running simulations in multiple threads #67

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Create two or more DynamicsWorld instances, each in its own thread.
2. Call each DynamicsWorld's StepSimulation() from its respective thread on 
every frame.

It's important to only access each DynamicsWorld from a single thread. Doing so 
should avoid threading issues.

What is the expected output? What do you see instead?
I expect StepSimulation() times to remain consistent but instead they increase.

What version of the product are you using? On what operating system?
I'm using BulletSharp r626 compiled with Bullet r2709 (Generic release and 
generic debug versions). The same issue occurs in the pre-compiled BulletSharp 
2.82 (Generic release version).

Please provide any additional information below.
I've attached a test application that reproduces the issue on my machine. It 
should take only a few minutes for the issue to become apparent.

To help pinpoint the issue I compiled a debug build of BulletSharp r626 with 
Bullet r2709 (Generic version). Then I used it to run the test program for 
around 5 minutes. During that time the average StepSimulation() time increased 
from 0ms to 21ms. Then I attached a profiler to the program. The profiler 
results showed that, ironically, 96.11% of the time was being spent in 
CProfileNode::Reset(). I've attached pictures of the test application and 
profiler results along with the profiler results themselves.

A few additional notes:
- I'm not sure that this is a BulletSharp-specific issue. It may be a bug in 
Bullet itself. I decided to report it here just in case.
- Stopping the physics threads doesn't return the performance to a baseline 
state. Once the performance has degraded, the only way I've found to fix it is 
to restart the entire program.
- The test application uses empty DynamicsWorlds. Nothing is ever added to them.

I've been working on a single player / multiplayer game. Since single player 
mode requires running the client and server in the same process this issue 
makes it unplayable after about 30 minutes.

Original issue reported on code.google.com by shiny....@gmail.com on 30 Apr 2014 at 11:38

Attachments:

GoogleCodeExporter commented 8 years ago 
Interesting, I got the same thing. The profiling code in Bullet is common for 
all threads and there seems to be no thread safety implemented for it.

The P/Invoke version doesn't seem to have this problem for some reason. I still 
got 0 ms.

Compiling Bullet with BT_NO_PROFILE should help.

Original comment by andres.traks on 1 May 2014 at 1:28

GoogleCodeExporter commented 8 years ago 
I'm not sure why it wouldn't happen when using the P/Invoke version. Maybe a 
difference in timing is causing Bullet's profiling code to react differently. 
I've also experienced it not occur, but usually it would resurface the next 
time the test application was run.

Things are looking good now, though. As you suggested, I recompiled with 
BT_NO_PROFILE which seems to have fixed it. I've run the test application 
several times with the new build and StepSimulation() times are staying put at 
0ms. In-game physics times are remaining stable as well. Your help has been 
very appreciated.

Original comment by shiny....@gmail.com on 2 May 2014 at 12:02

GoogleCodeExporter commented 8 years ago

Original comment by andres.traks on 28 Aug 2014 at 8:06