Performance Issues
See original GitHub issueHi!
First off I’d like to give my thanks for creating this library, we’re enjoying using it on our project.
I would like to discuss some performance issues we’re having, potential fixes, and whether these are something you may consider being part of the core library offering.
Initially, I’d like to share a screenshot of our graph, so you can get an idea of what we’re working with.
Now, we’re facing several issues:
- Load time takes 1min+ in Firefox, and even longer in chrome.
- Connecting nodes on the edges, can take 15-20s+ on chrome (although stay within a couple of seconds in Firefox strangely).
I’ve boiled this down to the fact that CalculateOrder
function, which runs every time we CheckConnection
, is run:
- Every time we load a graph, the library attempts to re-add every node’s connection and this function gets called for every node X>Y
- Every time we try to connect 2 node’s (after load).
Here’s what happens every time a node is connected:
- We run a DFS, with cycle check for every node with no outputs (E.G for this particular graph that means we’re running a DFS 37 times across the graph once nearly every connection is added, for every output node we have)
- Once we have the full path for each output node via the DFS, run a BFS across the node’s, so the baklava engine can calculate the order to run node’s.
Suggested changes?
-
Allow the
CalculateOrder
check for each node to be optional when calling load, it doesn’t seem like there’s always a need to do that when we’re already running the checks every connection we add. This change alone make’s load run in <1s for FF/Chrome -
Decouple the generation of baklava node execution order, from the cycle checking.
Myself (and perhaps others) are actually just using Baklava as a graph rendering Vue library (then using the save/load feature when done, and running the graph on the server using our own execution logic).
If we were to remove the BFS check / make it optional via some sort of opt in engine config parameter, it speeds up node connection (worse case) from ~20s to ~2s in chrome. It must be noted I am noticing weird behaviour in the fact Firefox seems to be able to handle the stack generated here of ~5mil items on some connections extremely fast, compared to chrome which completely chokes.
Would appreciate any thoughts you have regarding the above!
Thanks
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:7 (4 by maintainers)
Second this!
Implemented in v1.10.0