News

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

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


Share
Filter by section
Most popular stories
Mob Rules - Moving to Virtual Pair Programming

Mob Rules - Moving to Virtual Pair Programming

Like all companies, lockdown has impacted the way we work at TransFICC. We have always championed Extreme Programming as our methodology of choice, so when we decided to close the office at the start of March, this raised some issues around how we would operate with everyone working remotely.


Read More Twitter LinkedIn
All Change - Technology & Efficiency Are The (Old) New Buzzwords in Fixed Income

All Change - Technology & Efficiency Are The (Old) New Buzzwords in Fixed Income

Steve writes for The Financial Technologist - published by Harrington Starr


Read More Twitter LinkedIn
Press Release - TransFICC Secures New Investment From AlbionVC, ING Ventures and HSBC

Press Release - TransFICC Secures New Investment From AlbionVC, ING Ventures and HSBC

TransFICC has closed its Series A investment round for £5.75 million. Led by AlbionVC, it included new strategic investments from ING Ventures and HSBC. The new investors join existing shareholders, Citi, Illuminate Financial, Main Incubator (the R&D unit of Commerzbank Group) and The FinLab.


Read More Twitter LinkedIn
Twitter Feed