I’m trying to graph some real-time data, “realtime” here means < 10msec data, ideally as low as possible. I’ve been able to get Android to fetch and process data this fast but ACE just looks like it’s not been designed for real-time use in mind. First symptoms are that garbage collector kicks in like there’s no tomorrow and totally kills the app. I’m visualizing data on a “sliding window” fashion so it’s not like I’m expecting ACE to plot in real time hundreds of thousandths of points.
I’ve taken a look at it and the onDraw for XYChart certainly allocates very heavily in cases where it looks like it’s convenient and probably makes the code much more readable but not really required.
This might even be worse than it used to be so it might not have been noticed yet. I saw bugfix for issue #225 solved a concurrency problem changing:
return mXY.subMap(start, stop);
for:
return new TreeMap<Double, Double>(mXY.subMap(start, stop));
This creates huge allocations (still backed by the original subMap though) when it would probably be better to queue updates while onDraw is going on and process them later on atomic updates or something on that line to avoid concurrency issues.
The real pity here is that ACE is certainly fast enough for what I need. It can do what I need on my HW perfectly but since it allocates so heavily on repaint Android goes crazy with GC. It soon starts allocating while GC is running so it has to wait and my app starts looking like a stop-motion movie.
The real question though is: Is it reasonable to expect to be able to repaint 4 or 6 linecharts (tablet app) on realtime (sub 200ms refresh rate) with ACE or is it simply not prepared for that kind of abuse?
If the answer is no. Any other options there you’d recommend?
EDIT 20130109:
Revision 471 improves things quite a bit for small data sets. 2.000 points / 4 charts / 100 msec refresh rate is doable and smooth. Logs still see “GC_CONCURRENT freed” like crazy (around 10/sec) but no “WAIT_FOR_CONCURRENT_GC blocked” which are the showstoppers that make your app stop-motion like.
At 3.000 points / 1 chart / 100 msec it’s clearly not smooth. We get again the avalanche of “WAIT_FOR_CONCURRENT_GC blocked” on logcat and the stuttering app. Again it looks like we do not have a speed problem, only a memory management problem.
It may look like I might be asking ACE to do magic but I hit this wall after refactoring all my code to retrieve and store telemetry data at 1KHz. Once I finally saw my app retrieve and store all of that realtime without triggering GC at all I pulled my hair with ACE when trying to graph 🙂
After a big effort on optimizing everything else on my app I still can’t make it plot in what I understand for “realtime”.
The library is great, and very fast but the way in which every onDraw allocates memory inevitably triggers an avalanche of garbage collection which collides with its own allocation and thus android freezes your app momentarily causing stutter which is totally incompatible with “realtime” graphing. The “stutter” here can range from 50-250ms (yes milliseconds) but that’s enough to kill a realtime app.
AChartengine will allow you to create “dynamic” graphs just as long as you don’t require them to be “realtime” (10 frames/sec, (<100ms refresh rate) or what you’d call “smooth”).
If someone needs more information on the core problem here, or why I’m saying that the library is fast enough but memory allocation patterns end up causing performance problems take a look at Google I/O 2009 – Writing Real-Time Games for Android