The sample app included in my GBC Object Pool plugin has a performance scene that compares object pooling to traditional object creation. I took that scene, and modified it to execute 100 times automatically. After each run, it dumped the amount of time it took to execute.
Here are the results I experienced using the following settings in the app:
- Display 100 images, 200 times
- Use colors, physics, and scaling
- Display the images using traditional methods, then pooling. Record both times
- Repeat 100 times
Note that while the app is running, I did not attempt to access the devices, and no other apps were running in the background. Basically, I ran the app, clicked Start, and walked away.
Windows Desktop Performance
For this test, I used my development machine… a 2 year old Dell XPS 8700 with 16GB RAM.
Notice the tightness of the pooling times? GBC Object Pool (and object pooling in general) is pretty consistent, operating on average around 6700 milliseconds to perform the task.
The blue dots represents the traditional method of creating 200 images via display.newImageRect() 100 times, and then removing them. Notice the sporadic times and wide distribution. The dotted line represents a linear average where 50% percent of the dots are above the line and 50% are below the line. Notice that all of the object pooling tests are mapped below this line.
Android Performance
Moving on to smart devices, I used my Android phone… a 2+ year old mid-range Samsung.
Again, notice how pooling provides a more consistent result and maps faster than traditional average times?
What is interesting is the first few items between run 1 and run 10 (and again between run 61 and 75). Check out the data listed here:
Run |
Traditional |
Pooling |
Difference |
1 | 7706 | 6678 | -13.34% |
2 | 7962 | 6722 | -15.57% |
3 | 8844 | 6671 | -24.57% |
4 | 7787 | 6680 | -14.22% |
5 | 8030 | 6651 | -17.17% |
6 | 8243 | 6739 | -18.25% |
7 | 7679 | 6928 | -9.78% |
8 | 7221 | 6846 | -5.19% |
9 | 7278 | 6988 | -3.98% |
10 | 7318 | 6886 | -5.90% |
Something definitely was happening on the phone (memory allocation? background OS task?), but you will notice that it wasn’t a noticeable factor when using pooling. Since it is not possible to know when or if a background task will start executing while a user is playing your game, I would expect the game to stutter if you were creating a lot of objects during this time via the traditional method.