You might recall that back in February Tim Lin posted some graph benchmarks, and LightGraphs did reasonably well. In my post at the time, I mentioned that Tim was going to re-run the benchmarks in a few months. Well, he’s just published the latest results with a TON more detail than last time.
I encourage you to read the entire thing, but I realize that it’s a long post. So, here’s the bottom line:
The same packages were tested again: Snap, igraph, networkx, graph-tool, networkit, and LightGraphs. NetworkX and LightGraphs were the only single-language packages tested.
Tim used the master branch of LightGraphs which will eventually become version 2.0. This uses a dispatch-based API with some significant performance improvements, especially in the multi-threading code.
Tim compared multithreading code (he did last time too, but we didn’t have a good story to tell in the 1.3 series) where it was supported in the packages.
LightGraphs tied or beat every other package tested, across every graph type, in every test except for graph loading. Where we beat a package, it was usually by a significant amount.
Here’s an example for the Google-web graph (values are times in seconds):
Some notable quotes:
Lightgraphs is ~300x faster than networkx on the single source shortest path problem, and approximately 10x faster than the other competitors.
Once again, lightgraphs performs extremely well on the k-core decomposition, being more than >250x faster than networkx.
The move from lightgraphs 1.x to 2.0 has also led to significant all-round performance gains with many multi-threading algorithms now available.
Lightgraphs is an anomaly over here since it’s [sic] performance is really fast even on 1 thread and relatively consistent across all settings.
I’m very excited by this benchmark study – it validates a whole ton of work the core team has put into the package over the past several months.
I’d like to conclude with a call for help: if you have a chance, please check out the GraphIO.jl package. It needs some love, particularly in performance. The
Edgelist format is the one that was used here. It’s laughably unoptimized. Jump in the
#graphs channel in Slack if you have questions, and please open issues and/or PRs with suggestions.
Thanks to everyone in the Julia community for your support. This is a really exciting time to be part of things. We can’t wait to share version 2.0 with you all (later this summer, with any luck). In the meantime, if you want to get a taste of the changes, check out the LightGraphs master branch. (There are deprecation warnings throughout so your old code will work but will be really noisy and slower until you migrate to the new API.)