Don't Just Assume Array Will Be Faster When Implementing Object Pooling

By Tom McKee

To ensure customers receive the best service possible from TransFICC, we need to make sure that our systems have robust latency and throughput figures. A key part of avoiding latency spikes (in Java anyway) is to attempt to keep the Garbage Collector at bay. One way we attempt to do this is with the use of object pooling pattern to allow us to re-use objects.

We weren't sure what data structure would be best to back our object pool implementation, so we decided to write a few benchmarks that utilise various data structures: stack, dequeue based stack, queue, and an array. The goal of these benchmarks was to see if any of the data structures allocate (e.g. if using a LinkedList, a node would be created every time you added an object to the pool), and to see what the latency and throughput values would be.

The benchmark results for measuring throughput show that both of the deque backed object pools perform at a similar level for both of the scenarios we are testing, with our stack implementation having similar throughput for the removing and adding several objects scenario.

What is more interesting are the latency figures.

Both object pools that are backed by a deque have very similar latency profiles, which I was surprised at as I expected the stack implementation to outperform on the remove one add one strategy, as it would only be using a single object (the queue implementation will always be taking a different object from the front of the queue). The stack object pool does perform slightly better in the remove several add several scenario at one data point, but the difference isn't significant compared to the queue implementation.

What I found most surprising is the high variance in the array backed object pool. I assumed using a simple array would yield the best throughput and latency numbers, however this is not the case. I'm not sure if it's because of my implementation of the array object pool so will try another version if I have time.

In the end we opted to use an object pool using a stack backed by a deque based on our findings. I should point out that all our object pools are accessed from a single thread so are not required to be thread safe.

For Tom's full blog post (including graphs and code) visit http://tomsmalls.blogspot.co.uk/2016/06/object-pooling-in-java.html