#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:

#21

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.

1 Like
#22

This should be better in 0.8.9+

#23

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 :wink: