Render Queue Optimization

[Kovak]

I'm going to go ahead and take care of creating a test branch for when we have the memory profile ready.

Basically, right now all the _update loops keep track of a list of the objects they are rendering and then a render dict of the particular instructions for each object. Right now when an object is removed from screen it is popped from the first list, but remains in the render dict.

This branch will simply also have it popped from the render_dict.

Once we have a memory profiler working we can test to see if this is a significant change

[Kovak]

A semantic note first: you do not pop things from dictionaries you del them

Dictionaries have an O(1) lookup time but an O(n) memory usage, so theoretically for each additional object we were adding we were increasing the memory usage of that dictionary in a linear fashion. Given that platforms, coins, and mid/ground background objects were steadily increasing by like 2-10 every 10 seconds, we should have been steadily increasing memory usage by a linear but significant amount per each new object rendered on screen.

The branch 31-render-queue-opt-a now contains this change for midground, background, foreground, world objects, and enemy widgets.

Foreground for instance now hovers between 4-12ish objects in the render dictionary instead of adding 2 every 15-20 seconds.

Don't know if this change will be significant but once we get our tools for memory profiling we can immediately compare the 2.

[Kovak]

Added a new branch 31-render-queue-opt-b that contains both the changes to the dictionaries and removal of the quads from canvas. Merging decisions should not be made until the a and b branches are compared with current master_candidate with both memory and cpu profiling

[Kovak]

Based on some testing: it seems that 31-render-queue-opt-b is the most efficient branch memory wise containing the least functions with leaks as well as the smallest overall memory usage in comparision to

memory_profiler_a and 31-render-queue-opt-a

however we really probably need to develop a way to run multiple tests and get averages. Also I'm afriad the MB resolution on the profiler is missing a lot of the differences between these 3 branches