GraphRecipes.jl icon indicating copy to clipboard operation
GraphRecipes.jl copied to clipboard

Intermediate objects

Open mkborregaard opened this issue 5 years ago • 5 comments

Some of the graph algorithms take a long time to run when the graphs are complex. It's annoying to have to recalculate every time you want to change nodesize etc. Could we refactor to have the calculations done in a GraphLayout constructor and then just dispatch on that object, so you could save that as a temporary whenever calculations are slow?

mkborregaard avatar Mar 13 '20 15:03 mkborregaard

Wait, it may not actually be the layouting that is slow, but the actual plotting. My graph has 5000 edges - each edge is it's own series, and each series copies the entire plotattributes object. Could we refactor this to have all edges be the same series with NaNs in between?

mkborregaard avatar Mar 13 '20 17:03 mkborregaard

I also suspect that edges and layouts might be responsible for a significant amount of time. I remember when making the Watts Strogatz gallery example that the :stress method was way slower than the :spring method. Personally, I don't think that we should do any refactoring until we have some good data on the table. I think it would be a really good idea to do some serious benchmarking/profiling. We need to come up with a good list of performance sensitive examples and use profiling info to inform any refactoring decisions.

JackDevine avatar Mar 13 '20 21:03 JackDevine

Maybe. I think the "produce storable intermediate object and dispatch on that" approach is pretty ideomatic throughout the Plots ecosystem regardless though. But sure profiling is a good idea.

mkborregaard avatar Mar 13 '20 21:03 mkborregaard

Ok, now I can see that this feature could have value beyond performance, I think that it is worth adding. As long as we can keep the current API as well.

JackDevine avatar Mar 14 '20 01:03 JackDevine

For vizcon it would be great if someone could start with profiling though

mkborregaard avatar Mar 14 '20 06:03 mkborregaard