Sunday, December 12, 2004

Performance issue ... solved

I finally figured out what was going on with Orion's performance issue, and why it was hard for me to find it. Turns out that Andreas modified the #stepTime method to return 20, instead of 0 as it was originally. Later this was modified to return 1 if the highPerformance setting was enabled, which it usually isn't. When I set this flag in the preferences, I had essentially the same frame rate with the current Jasmine change set as with Orion's older pre-change version.

I speculate that the reason he had an increase in frame rate when he put another morph on top of the TeapotMorph was that the other morph was updating at fullspeed, which would of course force the underneath morph to update at the same rate.

This was hard to figure out, because I was always testing with larger worlds on machines that were slower than what Orion has. That is, I couldn't usually even get close to 40 Hz update rates with what I was usually doing, so the #stepTime didn't really matter much, as I was running less than this speed. The reason there was such an unevenness to the performance that Orion also noticed was that we use the morph render time to also update and process the future and remote message queue. The longer the delay, the more messages that would qualify for computation.

No comments: