Processing 1.0 - Processing Discourse - how to avoid jitter from garbage collection?

We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.

Index › Programming Questions & Help › Programs › how to avoid jitter from garbage collection

‹ Previous Topic | Next Topic ›

Pages: 1

how to avoid jitter from garbage collection? (Read 880 times)

Aaron B

how to avoid jitter from garbage collection?
Jan 30^th, 2010, 10:05am

Hi, I am noticing jitter in my animation. (My animation is basically just a couple dozen 2D shapes that are drawn with different positions on each draw() cycle.) My actual frame rate stays in the range of 30-40 per second. However, once or twice per second, I get a frame that lasts 2-4 times as long as it should (as detected by measurements built in to the code). Since my object positions are drawn as a function of millis(), their future positions are not affected by the jitter, but the dropped frames are visibly disturbing.

My draw() method usually does a trivial amount of work, but does a larger amount of work at periodic intervals. I noticed that the "dropped frames" roughly coincide with the calls to draw() that do more work, BUT if I call System.gc() in between the frames that do more work, then the dropped frames coincide ONLY with the frames in which I manually trigger the garbage collection. (So I infer that the computation-heavy frames are only slow due to their side-effect of automatically triggering garbage collection.)

SOOOO....what is the solution to this problem? My experience with animation programming is quite limited, but this is a problem that one might well expect to have in a language with GC. Is there support in Processing for Java's real-time garbage collectors? Do I just need to try to do less allocation? Do I need to abandon Processing for some other language?

- Aaron

th0m

Re: how to avoid jitter from garbage collection?
Reply #1 - Jan 30^th, 2010, 10:41am

Hey there, I ran up against this in a kiosk a while back, and I think it is a trade-off scenario, and depending on complexity, you'll run into this in any language. Also, Java has the JIT compiler, which speeds up parts of the code it has seen before. I could recommend two approaches, balancing, reduction. For balancing, basically consider dividing your work up better between frames. Try to make every frame do the exact same amount of work, regardless of what the animation may be doing. Specifically this would be a state-machine check that always performs the same no matter what state, or even something ugly like checking for everything all the time no matter the state. The goal is consistency of the workload between frames. To then get a consistent timing (if not somewhat inaccurate), cross-reference frameCount and millis().

Reduction I guess would be just to be doing the simplest thing possible during the actual animated loop, and do as much pre-setup of objects and variables (and especially object instantiation, memory allocation, file operations) beforehand, or like above just be doing it all the time.

Hopefully this helps, and yeah maybe try it in another language and come back? Just some thoughts.

PhiLho

Re: how to avoid jitter from garbage collection?
Reply #2 - Jan 30^th, 2010, 11:08am

Yes, there is a real-time Java (or Java library for real time stuff).

GC time is a well known problem for real-time animations (games...), indeed. Lua language, which is used a lot in games, switched to an incremental mark-and-sweep collector which works more in parallel, resulting in less or no visible stop.

You can also play with GC options, but it is a quite complex topic...

"Do I just need to try to do less allocation"
It might be an option... Sometime, slow down can result from "poor" programming practices, or, say, optimistic ones - supposing a programming way is OK because the Java compiler will do a good job -- but some optimizations, like escape analysis, must be kicked in explicitly!.
An example is JBox2D: author used a lot of little intermediary objects to return compound values (eg. pairs of coordinates) from methods. They discovered than avoiding these numerous short-lived objects boosted the performance...

Pages: 1

‹ Previous Topic | Next Topic ›