Eliminate GC-induced stuttering during animations by eliminating wasteful allocations

[tonypatino-monoclesociety]

I noticed that the Realtime chart demo can stutter due to many repeated and wasteful allocations in sections of code that are called in each update of the data, and it would be great to smooth out the animations and remove stuttering. I've so far identified, verified, and tested ways to reduce the number of allocations by approximately 70% and memory consumed by about 30%, with an attendant improvement in animation quality through various means, such as:

1. Eliminating the use of convenience iterations in favor of old fashioned iteration.
   for(;;){} instead of
   for(Object foo : inSet){}
2. Caching the results of String Formatting and using those cached results when the value in the dataset has not changed
3. Using field level references to store short-lived instances within methods and re-setting them instead of instantiating a new one
   eg 1: instead of instantiating a float[] temp = new float[2]; inside a method
   declare the float[] as a private field and initialize its two locations as needed.
   eg 2: instead of instantiating a new Matrix inside of a function, create a Matrix field and call matrix.reset(); where previously a new Matrix would be instantiated.
4. Pre-instantiating runnables outside of a local Thread object's run method when each Runnable instance performs the same action on the same object instance

Other means that I have not yet explored but deserve some research include using object pooling for frequently instantiated objects such as FSize, PointF, and the like.

Attached are the results from the memory monitor in Android Studio

allocationsComparison.zip

[PhilJay]

Thanks for the input, I know there is definitely some space upwards regarding performance.

I am currently crazy busy with other optimizations of the library regarding v3.0 release, so if you could point me to the exact areas in code where the most speed is "left behind" that would be great and it could save me some time when I work on the changes. Thanks!

[tonypatino-monoclesociety]

No worries about the schedule, Phil. I've been considering various ways to up the performance in the library, and they aren't all fully tested yet, but I'd be happy to create a pull request with my findings so far. The largest gain I found was related to #1897 which there's a pull request for.

The biggest hurdle at this moment is the amount of work performed on the UI thread. Since much of the calculation is done inside of onDraw instead of pre-calculated in a worker thread, things can look a little stuttery from time to time.

Another option might be to give users an option to set a desired framerate, such as mChart.getRenderer().setDesiredFramerate(int). If we know that some charts will require so much processing that they can't reach a solid 60fps then perhaps we can offer users the ability to request a refresh rate of 30fps. While less detailed, a more consistent framerate usually looks a bit better overall.

[tonypatino-monoclesociety]

allocationsComparison_2016.06.24.zip

Above, I've attached memory usage comparisons on a Nexus 6 across the master branch, and across the feature branch. While the logs are specific, they are representative of the average. A summary:

=================================
=================================

Master @ 500 entries
3 Threads
~65000 allocations on Main thread, totaling ~4.1MB allocated
0 GC runs during the 500 entries.

Master @ 5000 entries
4 Threads
~65000 allocations on Main thread, totaling ~30.5MB allocated
15 GC runs during the 5000 entries.

=================================
=================================

Feature @ 500 entries
3 Threads
~13500 allocations on Main thread, totaling ~0.5MB allocated
0 GC runs during 500 entries

Feature @ 5000 entries
3 Threads
~64000 allocations on Main thread, totaling ~2.4MB allocated
0 GC runs during 500 entries

=================================
=================================