...
| Code Block | ||
|---|---|---|
| ||
Java _______________________ 0 - 2 producers 2 consumers: 4,782,614 ops/sec - MapsPerfTest 1 - 2 producers 2 consumers: 4,194,545 ops/sec - MapsPerfTest 2 - 2 producers 2 consumers: 4,726,670 ops/sec - MapsPerfTest 3 - 2 producers 2 consumers: 5,339,190 ops/sec - MapsPerfTest 4 - 2 producers 2 consumers: 4,952,414 ops/sec - MapsPerfTest Cliff's ______________________ 0 - 2 producers 2 consumers: 23,030,573 ops/sec - MapsPerfTest 1 - 2 producers 2 consumers: 31,244,208 ops/sec - MapsPerfTest 2 - 2 producers 2 consumers: 30,630,539 ops/sec - MapsPerfTest 3 - 2 producers 2 consumers: 28,825,699 ops/sec - MapsPerfTest 4 - 2 producers 2 consumers: 26,588,300 ops/sec - MapsPerfTest Long2ObjectMap (FastUtil) ______________________ 0 - 2 producers 2 consumers: 5,569,578 ops/sec - MapsPerfTest 1 - 2 producers 2 consumers: 5,940,526 ops/sec - MapsPerfTest 2 - 2 producers 2 consumers: 5,883,532 ops/sec - MapsPerfTest 3 - 2 producers 2 consumers: 5,798,396 ops/sec - MapsPerfTest 4 - 2 producers 2 consumers: 5,537,185 ops/sec - MapsPerfTest |
Saving With NonBlockingHashMapLong
Taking the map sizes reported by the indexing structure, we can easily check what is the expected size of indexing structure if the map would be changed to NonBlockingHashMapLong:
| Map # | Number of elements | App. CocnurrentHashMap size | App. NonBlockingHashMapSize |
|---|---|---|---|
| 1 | 17245 | 1,380,273 | 478,677 |
| 2 | 300778 | 24,073,989 | 8,348,829 |
| 3 | 4554 | 364,497 | 126,407 |
| 4 | 32965 | 2,638,487 | 915,024 |
| 5 | 644 | 51,721 | 18,348 |
| 6 | 10604 | 848,734 | 294,339 |
| 7 | 598 | 48,026 | 17,038 |
| 8 | 10604 | 848,734 | 294,339 |
Total | 377992 | 30,254,461 | 10,493,001 |
As seen with change to high scale lib we would gain the storage optimization of almost 20MB (for given example), or decrease of 67%.
Further options to optimize indexing tree size
Simplest option would be to decrease the number of elements indexed. We can re-think on our use-cases and real need to index every single element that is in the buffer (timers and SQLs we often need in aggregated mode only).
The other option to optimize the indexing tree size would be to go away from the maps and implement different structure.
The additional option would be not to map the element ID with the element it self (that's what we store in maps). Because the element ID is only needed for direct element retrieval and this use case we have only for invocation sequences. Thus for everything else we could spare that space by holding the elements in the array list for example.