2 ms·
Note while the package renderer (your last link) is impressively fast, it's only a renderer. It consumes a graph that has already been laid out; layout is compu
by lobster_johnson 11y ago
Note while the package renderer (your last link) is impressively fast, it's only a renderer. It consumes a graph that has already been laid out; layout is computationally more expensive than just rendering it. (It can also work with a layout, but that won't scale in real time to those Internet-wide graphs.)
- eggie 11y agoFor layout I have found nothing faster than mars https://github.com/marckhoury/mars https://github.com/marckhoury/mars. I have to work with graphs of hundreds of millions of nodes. Just looking at fragments of them of tens of thousands of nodes in reasonable time requires something like mars. I have not found anything else remotely as scalable.
- lmeyerov 11y agoHi Eggie, any way to contact you? Would love to see how to improve our workflow to help what you're doing! (And we regularly layout hundreds of thousands of nodes in real-time, so sounds like a great stress test!)
- eggie 11y agoHi lmeyerov, I'll reach out by emailing you on GitHub or via graphistry. Unfortunately, I won't be able to use anything proprietary in production. Also I need solutions that are self contained executables and capable of scaling to several billion nodes. External APIs are a no-go. That said I'm happy to talk as it looks like y'all are doing cool things :)