OK, another performance puzzle

Official forum for the Chipmunk2D Physics Library.
Post Reply
ideal57
Posts: 23
Joined: Fri Apr 03, 2009 4:36 pm
Contact:

OK, another performance puzzle

Post by ideal57 »

I have a stack of square poly shapes sitting on a single static segment (floor). There as 8 columns of 13 rows which are 2 px apart between columns and 1 px in rows. There is a tiny gravity field pulling on them down.

When the sim starts I get 30 fps (on iphone, no thumb, release config (all inlines) ) as the squares start to touch the fps drops to 7.

50% of the runtime is in one routine, cpArbiterApplyImpulse(), 20% in cpHashSetEach()

The squares are 28px in size, I called cpSpaceResizeActiveHash( space, 32, 1000 ); shape->e = 0; shape->u = .7;

I tried both a fixed time step (1/30/6) and one based on the incoming time, no diff.

Any ideas? My last game (still not approved, argh) steadily got 30fps.

Also, this is the trunk code.

I even got rid of the gravity, just created the squares with no vertical gap (so they are touching) and no floor at all and Im looking at 4fps. Same result. It seems that the contact between the squares is somehow eating up enormous cpu time. With a 1 px gap (and thus no contact) fps is rock solid at 30fps.
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: OK, another performance puzzle

Post by slembcke »

It is usually the case that the impulse solver (most of which exists in cpArbiterApplyImpulse()) takes up the most CPU time. Each contact point in the space has to be calculated separately. The iteration count specifies how many times to loop over the constraints. So the impulse solver cost is directly proportional to the number of contacts and the number of iterations. Keep in mind that with poly to poly collisions each contact pair probably has 2 contact points per pair of objects.

So when you have 8x13 objects, each probably with an average of 4 contact points per object. Leaving the iterations on the defaults means 10 elastic iterations and 10 normal iterations. That is over 8000 contact point solutions to process! Very expensive for a tiny processor! See what you can do to cut that down by reducing the number of objects or the number of iterations used. If you aren't using elasticity at all, set that to 0.
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
ideal57
Posts: 23
Joined: Fri Apr 03, 2009 4:36 pm
Contact:

Re: OK, another performance puzzle

Post by ideal57 »

I made elastic iterations be 0, changes the steps in the spacestep to 3 and the iterations to 5 which helped. Now cpHashSetEach() is taking 50% of the time. I assume this is because the squares are all in contact with each other, making the hash less effective. Anything I might do here to make this faster? I'm up to 12-15 fps now. This is a worst case test basically, I figure if 100 objects can be fast enough then the average case will be much better.
ideal57
Posts: 23
Joined: Fri Apr 03, 2009 4:36 pm
Contact:

Re: OK, another performance puzzle

Post by ideal57 »

handleQueryRehashHelper by itself takes 1/6 of the time plus a slightly lesser amount being all the query functions. Maybe I can find some optimization here since this is called every spacestep(), and my objects generally don't move far.
User avatar
slembcke
Site Admin
Posts: 4166
Joined: Tue Aug 14, 2007 7:13 pm
Contact:

Re: OK, another performance puzzle

Post by slembcke »

If handleQueryRehashHelper() it's because it's iterating a lot of spatial hash cells. Are the cell dimensions similar in size to the objects you are putting in?
Can't sleep... Chipmunks will eat me...
Check out our latest projects! -> http://howlingmoonsoftware.com/wordpress/
ideal57
Posts: 23
Joined: Fri Apr 03, 2009 4:36 pm
Contact:

Re: OK, another performance puzzle

Post by ideal57 »

cpSpaceResizeActiveHash( space, 28, 1000 );

#define BLOCKSIZE 28

I've tried 32 for the hash dim as well but made no difference. The blocks are all mashed together so maybe the hash doesn't work too well for a dense packing?
ideal57
Posts: 23
Joined: Fri Apr 03, 2009 4:36 pm
Contact:

Re: OK, another performance puzzle

Post by ideal57 »

Playing around with settings, if I make call cpSpaceStep only 60 per sec then the fps is OK. Maybe what I can do is step less if there are more objects. Changing the hash cell size only makes a minor difference, cpArbiterApplyImpulse() seems to always be 30% no matter what I set other stuff to (other than changing the #iterations). I guess the key with this is to adjust the parameters based on the count of objects, which will start at 1 and grow to maybe 100. A followup app will start with 60-80 and won't change. I can live with this.

I didn't realize on the iphone that the phone part takes 20% off the top. My test app was only getting 60-70% of the CPU time. Amazing this works at all.
ideal57
Posts: 23
Joined: Fri Apr 03, 2009 4:36 pm
Contact:

Re: OK, another performance puzzle

Post by ideal57 »

Gag I am a moron. I had stupidly created the bodys at 0,0 and made the shapes vertexes be world coordinates. I think that's why some of the results were so bogus.
Post Reply

Who is online

Users browsing this forum: No registered users and 17 guests