#1

Steps to reproduce

  1. Open a vault with 1000+ notes
  2. Open graph view in a panel
  3. Open an existing note in edit mode
  4. Add and delete [[wikilinks]] inside that note

Expected result

The graph should auto-update as you add/remove links. The editor should remain responsive. Everything should go smoothly.

Actual result

The graph view blocks the editor while it’s updating. You can’t type anything before it’s finished rendering the updated graph.

Environment

  • Operating system: macOS Catalina

  • Obsidian version: 0.8.8

Additional information

If instantly rendering the updated graph isn’t doable (like I believe it isn’t), I think it would be preferable to let the graph lag behind the editor a few seconds.

Maybe even better (considering that some of us have better computers), allowing users to turn off auto-update in the graph view panel (in which case a “refresh” button would be needed).

1 Like
#2

Thanks for your report.

Both of these seem like good solutions. I suspect that there might be some other tricks up the devs’ sleeves, though—maybe a way to separate threads for graph processing and the editor so that editing doesn’t get blocked.

Curious: what are the specs of your computer?

1 Like
#3

This is happening on my work computer:

Screenshot 2020-08-25 at 14.56.26
Screenshot 2020-08-25 at 14.56.261396×958 188 KB

With my 2015 iMac it’s a lot worse, though.

#4

Huh, that should be plenty of performance. A follow-up: what resolution do you run your monitor(s) at?

#5

Yeah, I never had had any complaints. This seems too serious a lag, even for an electron app.

The built-in at 1680 x 1050; the external at 3008 x 1692.

#6

Do you mind testing it at a lower resolution? Not that that’s a solution, just curious.

I have had significant performance issues with canvas elements at high resolutions.

#7

I’ve just tried disconnecting the secondary display and setting the built-in screen resolution to 1024 x 640.

Apart from a slightly smoother animation while dragging the graph, I couldn’t notice any improvement. There’s still a 5–10 second freeze.

In case it helps with anything, I also tried deleting the .obsidian folder.

#8

side question: which of your GPUs\CPU is doing the work?

#9

Only the CPU, apparently.

It spikes up to 140%, while the GPU’s just chillin’ at 0%.

OK, I was hasty and a bit unfair.

  • The Obsidian Helper (Renderer) process takes the CPU to 130% and the Obsidian Helper (GPU) takes the GPU to 60% when dragging and zooming
  • When typing in wikilinks, the CPU goes up to 100+% and the GPU goes up for a bit but comes down to zero quickly.
#10

I am a little puzzled by these 130% number. But I am not familiar with macos process manager. Which of the two GPUs is doing the work?

#11

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.

#12

Top minds are on the case, FYI. Thanks for the report!

1 Like
#13

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.

#14

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.

#15

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!

2 Likes
#16

Sure. First thing tomorrow.

1 Like
#17

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.

3 Likes
#18

Sorry to hear that! So the bad lag is with local graph… sorry to hear that.

#19

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.

2 Likes
#20

Here you go! Have fun :smiley: