We are encountering problems with the layered digraph layout that is too slow in some cases.
We must clearly know the limitations because we must be very contractual with our customers (some cannot open their projects).
Is there any results of autolayout benches?
I’d like to have approximate times according to the number of nodes and the number of links, with best and worst scenario of complexity.
Our biggest projects are actually about 200 nodes for 700 links and cannot be opened.
That sounds like it should take a while but should not be too bad. Perhaps there are a lot of links that cross layers, which will distinctly slow things down.
Trying to characterize the performance is difficult. It really depends a lot on the kinds of graphs that are being laid out. How long is that graph of 200+700 taking?
My 200+700 takes 12 seconds (1.5Ghz) which is not so bad.
I’ve made some tests. My conclusion is that we must use subgraphs at maximum.
I’d like now to determine the correct number of groups to optimize the time : If I have n nodes and I auto arrange n1 subgraphs of n2 nodes so that n1+n2=n. Which is the correct value for n1 and n2? SQRT(n)?
Here are the results of my bench:
1 object linked to the others:
same as first situation but with groups of 50 nodes:
You can clearly see that this is exponantial (try an excel chart)
If your graph is naturally decomposable into subgraphs, that would be reasonable to do. The typical case of this is where you are actually using GoSubGraphs (which are nodes) to hold graphs nested inside. The Layout User Guide describes how to do this, and the SubGraphApp demonstrates the code. But you need not be using GoSubGraphs to use this technique.
However, it only works when you can assume there is no interaction between nodes in the separate layouts. I have no idea if that applies to your situation.