Results - Gee
Perfbar
This is a performance report comparing the performance of a custom-built linked list with hand over hand locking vs. the built-in Java ConcurrentHashMap. The scenario I have is I am maintaining a chain of test chambers. In the linked list, I need to make sure they are in order of the IDs of the "test subjects" contained within. With the hasmap, I could just insert the chambers. Periodically, workers will either check in on the chambers and read details, otherwise they will generate a new test chamber and stick it in the chain. In the case of the hash map, I opted to have the workers use UUIDs for IDs and have their test chambers pregenerated on initialization. Both determine writes based on a combination of the number of initial chambers and a weighted coin flip 80% in favor of reads. I kept these the same for both sets.
This project went through a few iterations of creation, and needed to be switched from workers extending Thread to implementing Runnable in order to play well with the benchmarks. Additionally, hand-over-hand locking is an ugly way to handle a data structure, and its non-blocking nature made it so that I could not implement try-finally blocks to be sure everything always unlocked.
Results were surprising. Consistently, the linked list seemed to do better than the ConcurrentHashMap, though the gap wasn't significant. Below are the results, using a combination of workers and threads. Throughput is presented in ops/µs. For Gee, I included a couple Perfbar screenshots to show the benchmark was doing something.
Note that both had performance hits when the number of workers increased, likely due to increased contention for writes. The results seem to point to the linked list as being the more performant structure to use, though I would say performance gains are negligible. I would still go with ConcurrentHashMap, due to the listed issues with the linked list and locking scheme, as well as the fact that the built-in data structure is tried-and true