Aha
Apart from a slightly smoother animation while dragging the graph, I couldn’t notice any improvement. There’s still a 5–10 second freeze.
I think there’s two different issues here. One is GPU/canvas and graph animation, the other is cache processing and rerendering the model the graph represents.
I’d bet the cache processing (or whatever’s happening in the backend) is the source of the blocking and is causing the CPU activity.
Top minds are on the case, FYI. Thanks for the report!
You mean, above 100%? If so, I believe it involves multiple cores.
As for which GPU… I don’t know. Activity Monitor doesn’t seem to discriminate that. But I’ll look into it more carefully.
Can you please take a performance snapshot using the developer tools (performance tab) and send me the resulting file as a zip?
Click the circle button to start recording, do something that you would expect doesn’t lag, wait until it responds again, then click the circle to stop. Then use the arrow down button to save the snapshot and zip the file to make it smaller.
In the meantime, would recommend putting the local graph on the side. In most cases it might be more clear than the global graph, and it should render much faster.
Just an idea!
Sure. First thing tomorrow.
Thanks for the suggestion, @Silver. That’s actually what I’ve been doing.
The local graph is awesome, by the way. I never thought we’d have it so soon.
Sorry to hear that! So the bad lag is with local graph… sorry to hear that.
I’m sorry, I wasn’t clear. The local graph is perfect. What I meant is that I’ve been using it “instead” of the complete graph view as a workaround.
Here you go! Have fun 
Got it. Seems to confirm my suspicion about what’s causing the lag.
We’ll do an optimization pass on graph view a bit later which would address this issue.
This should be better in 0.8.9+
OK. Awaiting that version than because I also have lots of graph issues.
Prefectly understand it takes time to produce a graph.
I am using vaults with 80K+ articles in them (biggest).
The smaller vaults have 30K+ and 19K+ articles.
My Macbook is the newest generation so computing power enough 
I would agree, but you’d be surprised. Drawing canvas elements might look simple but it’s actually highly taxing, especially at high resolutions. I have a brand new max-spec Mac Mini (3.2 Ghz six-core i7, 64gb RAM, all SSD storage), and it also struggles. (Thinking about upgrading to an eGPU.)
Not that I doubt the devs’ ability to work some optimization magic… but I think expectations here need to be tempered. Point is, live-updating a canvas graph of tens of thousands of elements should probably be considered a high-intensity computing task akin to rendering high resolution video or computing a massive data model of some kind! Ergo, it might never be perfect.
Adding to the discussion, you may be interested in reading Performance issue after switching to Preview mode in v0.8.4
Performance optimizations is always an ongoing thing, and especially for graph view, which requires resolving links from each file, things gets quite computationally expensive when the file count goes up there.
There will always be a theoretical point for amount of files after which it will start impacting the app for your computer spec. A better computer certainly help; our optimizations also push it further.
Totally agree and no worries. One should ask what the added value of a 1K+ elements or even more is…
And I do understand perfectly that this takes a lot of computing power.
You are all doing an unbelievable great job! Thank you for that (really mean that).
You guys are already taking care of the optimisation issues. The 80K+ nodes are read in a minimum of time and also searching goes very quick.
You can always contact me when you need some testing capabilities on big vaults.
Delayed to 0.8.10
This is just to confirm that 0.8.10 solves this for me. Graph is much MUCH faster, even on my old iMac. And no more hang-ups while editing.
Cheers!
Thanks for confirming! Moving the bug to graveyard, since 0.8.10 is coming for everyone 