Routing with Eclipse Collections
I found days ago the Eclipse Collections library (ex Goldman Sachs Collections). Yes, that Goldman Sachs, one of the biggest investing banking group of the world, that for hobby creates super fast collection library for Java.
This article follows the previous, when I explored how to improve the routing of Vert.x Web, so please check it out before reading this one: Tree vs SkipList routing
What’s new
Three days ago, looking at my twitter wall, I’ve found a tweet about Eclipse Collections. I’ve found really interesting the performances of EC, so I’ve decided to put it into my benchmark and test it on our use case. I obviously choose the tree as data structure to rewrite the routing process of Vert.x Web, so I have write two variants of my original TreeRouter:
ECTreeRouter: A tree that internally uses List implementations of Eclipse Collections.ImmutableECTreeRouter: A tree that internally uses immutable List implementations of Eclipse Collections. In this case user can’t change the routing tree after routing has started.
The second option was a pure experiment: user creates the router and its internal tree doesn’t change during the application execution. In this case you have a simpler implementation and an immutable list (in some cases faster than a mutable one). I’ve also refactored only the SocialNetworkBenchmark, because we have similar results on ECommerceBenchmark.
Results
And, as in the previous articles, here comes the graphs:
And in the end the “final test” graph (now it does only random requests, not sequentially):
I have some considerations about these results:
- Eclipse Collections are fast to iterate, faster than JDK’s collections, so probably they are good for our use case. In particular, pay attention to particular events generated from benchmark data:
ECTreeRouteris faster than skip list in/feedrequest in “without load” tests! In particular it creates interesting deltas fromTreeRouterwhen we request constant paths…- But going deeper doesn’t help the
ECTreeRouter, in particular in “without load” benchmarks. We have too few datas to assert that at deeper levelsECTreeRouterdrops its performances or aligns it withTreeRouter ECTreeRouter, without any doubt, in the random requests test is faster thanTreeRouter
- Eclipse Collections contains a lot of optimized iteration patterns optimized, maybe useful for us
- It seems that EC thread-safe lists are faster than immutable lists, so the
ImmutableECTreeRouteris a failed experiment 😥
Unlike the previous post I’m little hesitant to give a verdict, but we have promising results with Eclipse Collections, so I want to start with it. In case we experience “not so good” performances after the implementation, migrate back to JDK’s collections doesn’t appear a complicated task
Stay tuned for other updates!