search

xexuxjy / bullet-xna

Automatically exported from code.google.com/p/bullet-xna
Other
21 stars 5 forks source link

[Info} Performance Profile Result #5

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
A friend of mine supplied an environment that they used to test and develop the 
parametric mesh generator.  It has about 1200 different mesh shapes for each of 
the different generation situations.  

The steps took about 1400ms with the scene in BulletXNA so I have not tested 
collisions on it yet, however, since BulletXNA was stressed, I figured I'd put 
it through a profiler and give you a report on the performance situation.

Original issue reported on code.google.com by dcoliva...@gmail.com on 19 Apr 2011 at 6:05

Attachments:

GoogleCodeExporter commented 9 years ago 
In the profile xml doc, you'd really only care about the Thread "Heartbeat for 
region Tester" and subtrees which is the first subtree under the Root element 
so it's easy to locate.

The other 7 subtree elements below that are the Network Stack, the Scripting 
Engine, the Services layer and other things that you probably don't care about 
:).

Original comment by dcoliva...@gmail.com on 19 Apr 2011 at 6:13

GoogleCodeExporter commented 9 years ago 
Thanks. is that an output from a particular tool? At a quick glance the 
simulation island building looks rather sluggish, especially in sorting and 
access to the object array. will do some checks this evening.

Original comment by xexu...@gmail.com on 19 Apr 2011 at 8:36

GoogleCodeExporter commented 9 years ago 
The output is the export from JetBrains dotTrace 3.1 with the Microsoft.* 
assemblies included in the report.   v3.1 is the last version of dotTrace that 
is both a performance profiler and a memory profiler.   

They currently have v4.0 on Performance and 3.5 on Memory profiling.  The XML 
is fairly close to the way it's displayed in the interface.  The interface 
gives you some hints on inlining results that the XML export doesn't.

Original comment by dcoliva...@gmail.com on 19 Apr 2011 at 3:54

GoogleCodeExporter commented 9 years ago 
Thanks. I've been using CLRProfiler and Eqatec to look at things but will try 
and apply for a license to dotTrace as well. Though the xml you provided was 
pretty readable anyway.

Original comment by xexu...@gmail.com on 19 Apr 2011 at 4:06

GoogleCodeExporter commented 9 years ago 
I've made a couple of small changes to UnionFind and the 
SimulationIslandManager which should speed them up. I still need to look at the 
sorting though as that was taking a while in your profile.

Original comment by xexu...@gmail.com on 20 Apr 2011 at 8:21

GoogleCodeExporter commented 9 years ago 
One bottleneck that I noticed in the profile is that it recalculates the AABBs 
of every object every time.   I peeked at CollisionWorld.cs and it looks like 
there's m_forceUpdateAllAabbs = true; in the constructor which is causing that.

Original comment by dcoliva...@gmail.com on 22 Apr 2011 at 10:58

GoogleCodeExporter commented 9 years ago 
Another bottleneck that I noticed is RayCasting.    It looks like there's an 
issue in the AABB calculation because it seems to be raycasting against every 
tri-mesh object.

The integration code Calls RayTest from the center of the capsule to 0.15 
meters below the capsule to determine if there is anything under it.   It uses 
the usual NearestNotMeRaycastResult example from the original c++ bullet that 
filters out contacts with the capsule.   When the capsule is suspended in air 
with impulse forces, there's no way that the ray is contacting anything.

Original comment by dcoliva...@gmail.com on 22 Apr 2011 at 11:46

Attachments:

GoogleCodeExporter commented 9 years ago 
The force aabb update defaults to true in the c++ version as well, the reason 
they give is that it's not completley reliable. You should be able to toggle it 
through the methods on CollisionWorld. I just did a quick test and TriangleMesh 
and BvhTriangleMesh don't actually do the expensive aabb check (RecalcLocalAabb 
- tests all triangles) on each call, only on initialisation. So that shouldn't 
be too bad either. Which collision shape are you using for your meshes?

Original comment by xexu...@gmail.com on 24 Apr 2011 at 6:53

GoogleCodeExporter commented 9 years ago 
I've made a few tweaks to the data types for the triangles and callbacks and to 
the quantized bvh as well. Can you let me know if this improves things?

Thanks,

Original comment by xexu...@gmail.com on 24 Apr 2011 at 9:18

GoogleCodeExporter commented 9 years ago 
I lost the computer that I was working on this with this evening to an 
electrical storm.   It might be a week or so until I get back to you.

Original comment by dcoliva...@gmail.com on 25 Apr 2011 at 7:48

GoogleCodeExporter commented 9 years ago 
Here's a picture of the server console and the stats while 'idle'.  No moving 
parts,  all static objects.  Many static objects.   29% one 3ghz CPU

Original comment by dcoliva...@gmail.com on 7 Jun 2011 at 6:12

Attachments:

GoogleCodeExporter commented 9 years ago 
Do you have another xml profile to go with that by any chance? thanks

Original comment by xexu...@gmail.com on 7 Jun 2011 at 6:39

GoogleCodeExporter commented 9 years ago 
No, but I can compose one in the morning :)

Original comment by dcoliva...@gmail.com on 7 Jun 2011 at 7:09

GoogleCodeExporter commented 9 years ago 
Idle and 'Load' XML profiles.

Idle reflects what it's doing in the picture.

Load reflects what it's doing while loading the scene into the physics layer.

Original comment by dcoliva...@gmail.com on 7 Jun 2011 at 8:06

Attachments:

GoogleCodeExporter commented 9 years ago 
Hmm, seems to have a ridiculous amount of time (percent) spent in absolute 
matrix / matrix ctor .... not sure whats going on there, i'll have a look 
tonight.

Original comment by xexu...@gmail.com on 8 Jun 2011 at 1:49