Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: A Graphviz Implementation in Rust

github.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Show HN: A Graphviz Implementation in Rust

#41

Post by graphviz »

fibonacci112358 wrote: post #17

How is performance compared to Graphviz? There are some large compiler Control flow graphs with 500+ nodes where Graphviz really starts to take a long time to build a layout (dozens of seconds or worse). Profiling dot a bit, saw that most time was spent doing some DFS, and a lot of the data structs seem to be linked lists, the opposite of cache friendly.

That DFS is in the network simplex algorithm that solves node coordinates.

Some nice clever person could probably code up that clever algorithm of Brandes and Köpf, https://link.springer.com/chapter/10.1007/3-540-45848-4_3

Some nice clever person could probably replace our 1990s-style network simplex solver with something that takes advantage of multiple CPU cores, too.

Re: Show HN: A Graphviz Implementation in Rust

#42

Post by philsnow »

jcims wrote: post #14

Nice! The general pattern I've encountered with graphviz is to start with it and hope you're done before it starts segfaulting on your data. Would be interesting to see if this helps. One of the things I rarely see in other graphing tools is the concept of node clusters. Super helpful in a bunch of situations I've encountered and wish it was more broadly implemented in other layout engines.

> The general pattern I've encountered with graphviz is to start with it and hope you're done before it starts segfaulting on your data

I've generated diagrams from various sources of data in AWS (security groups, EC2 instances w/ their attached security groups, edges between, etc) and never run into this issue. I'm talking thousands to tens of thousands of nodes and tens of thousands of edges.

The utility of these diagrams was limited, given how dense they were. I'm curious what use case graphviz chokes on that would generate legible graphs..

edit: this reminds me that it would be useful for the AWS APIs to return a "modification epoch" number inside API responses, so that while you're enumerating/describing thousands upon thousands of resources, you could at least keep track of whether there have been any modifications between your first and your last Describe* call.

Re: Show HN: A Graphviz Implementation in Rust

#43

Post by graphviz »

nikolayasdf123 wrote: post #35
amelius wrote: post #26

Has anyone tried building a graph visualization tool based on deep learning / GPU yet?

Yeah, more-and-more I am inclining building ML project for graph visualization. I have worked on graph visualisation for some time, did https://github.com/nikolaydubina/jsonl-graph and https://github.com/nikolaydubina/go-graph-layout Been studying research papers on graph visualization. It looks like we need some Deep Learning / ML based approach to this. There is just so much meaning is encoded into XY coordinates a…

You are drawing large graphs by hand?

ML approaches to graph layout are very exciting, since the constraints people need in real life diagrams are quite intricate, but it's still a research problem.

Re: Show HN: A Graphviz Implementation in Rust

#44

Post by tialaramex »

jll29 wrote: post #30
kevincox wrote: post #16

Earlier quoted context omitted.

It sounds like your rust is too old. IIRC the array FromIterator is only a month or two old.

Thanks, Kevin, that was it. I didn't expect Rust to (still) move that fast. ;)

This (arrays implementing IntoIterator) is probably the improvement with broadest impact of the last 12 months.

It even makes lots of Rust's documentation examples more readable. Previously if there's an iterator involved somewhere, the doc example ends up constructing say vec![1,2,3,4,5] and a reasonable novice might ask why do we use a vector here? Today Rust's documentation just says [1,2,3,4,5] because sure, an array of five elements 1, 2, 3, 4, 5 that makes sense why use any other data structure?

Re: Show HN: A Graphviz Implementation in Rust

#45

Post by monkeycantype »

wswope wrote: post #4

Does the standard implementation include any similar debug rendering? Seems like the coolest part of the project! I tend to stay away from Graphviz a lot more than I otherwise would these days due to the lack of manual formatting controls (have spent waaaayyy too many hours writing code to add invisible edges between certain nodes to force row-ordered layouts).

You can position everything manually exactly where you want it in graphviz without any of those tricks by using the neato engine.

I use scripts to manually place everything from data in csv files.

https://github.com/mathew-j-davis/boxesandarrows

Re: Show HN: A Graphviz Implementation in Rust

#46

Post by graphviz »

ZeroGravitas wrote: post #19

Don't know if it's a standard Graphviz thing but the text felt like it wasn't vertically centered in the bubble's.

We always had trouble with that too. Wasn't there another YC thread in the last couple of days about exactly this problem in typography.

Re: Show HN: A Graphviz Implementation in Rust

#47

Post by chrismorgan »

lambda_dn wrote: post #18

Quoted post unavailable.

Nah, it’s not new. Even remarking that the hot thing is reimplementing things in Rust is not new, you find at least one similar remark on almost every candidate thread. Remarking about such remarks is somewhat less common. :-)

Re: Show HN: A Graphviz Implementation in Rust

#48

Post by jcims »

philsnow wrote: post #42
jcims wrote: post #14

Nice! The general pattern I've encountered with graphviz is to start with it and hope you're done before it starts segfaulting on your data. Would be interesting to see if this helps. One of the things I rarely see in other graphing tools is the concept of node clusters. Super helpful in a bunch of situations I've encountered and wish it was more broadly implemented in other layout engines.

> The general pattern I've encountered with graphviz is to start with it and hope you're done before it starts segfaulting on your data I've generated diagrams from various sources of data in AWS (security groups, EC2 instances w/ their attached security groups, edges between, etc) and never run into this issue. I'm talking thousands to tens of thousands of nodes and tens of thousands of edges. The utility of these d…

Add 3-4 zeroes. Gephi is good for larger graphs but most of my use cases involve a compartmentalization context that isn’t part of typical graph layout semantics (including gephi).

None of these tools are actually appropriate for the job, just never get the time to build something better.

Re: Show HN: A Graphviz Implementation in Rust

#49

Post by nikolayasdf123 »

graphviz wrote: post #43
nikolayasdf123 wrote: post #35

Earlier quoted context omitted.

Yeah, more-and-more I am inclining building ML project for graph visualization. I have worked on graph visualisation for some time, did https://github.com/nikolaydubina/jsonl-graph and https://github.com/nikolaydubina/go-graph-layout Been studying research papers on graph visualization. It looks like we need some Deep Learning / ML based approach to this. There is just so much meaning is encoded into XY coordinates a…

You are drawing large graphs by hand? ML approaches to graph layout are very exciting, since the constraints people need in real life diagrams are quite intricate, but it's still a research problem.

yes. I would scale, zoom, adjust opacity, etc. Grouping into large/smaller clusters. Typically manual work is to do groups, their shapes, connections, how to highlight important info with colors or symbols and general meaning of X and Y axis. Very similar to drawing on a whiteboard. Whatever code I run, it is often very customized to make something exactly what I want.

ML would def benefits here to capture all these heuristics.

Re: Show HN: A Graphviz Implementation in Rust

#50

Post by andreareina »

graphviz wrote: post #46
ZeroGravitas wrote: post #19

Don't know if it's a standard Graphviz thing but the text felt like it wasn't vertically centered in the bubble's.

We always had trouble with that too. Wasn't there another YC thread in the last couple of days about exactly this problem in typography.

In theory you could rasterize and center the result in the box. In practice, good luck accounting for how ascenders and descenders alter the visual balance to make something that feels "right". I've spent way too much time fiddling with borders on my photos, I don't want to imagine working with something so unruly as text!
Post reply on HN