Extremely slow navigation in some files

[osa1]

Check for existing issues

• [X] Completed

Describe the bug / provide steps to reproduce it

• Clone https://github.com/dart-lang/sdk
• Open the directory in Zed
• Navigate to file sdk/lib/_internal/wasm/lib/convert_patch.dart

In the file start from the beginning or end and move the cursor up/down with arrow keys until the other end.

You will notice that it's fast in some places, then around the class _JsonStringDecoderSink (line ~1500) it gets extremely slow to the point where the cursor starts jumping a few lines as you keep pressing up/down, i.e. it can't render the intermediate states in time. Around those lines your PC will also start emitting a lot of heat.

The problem is not Dart specific, another example is this JS file: https://github.com/tree-sitter/tree-sitter-python/blob/master/grammar.js.

The same thing happens.

Environment

Zed: v0.148.1 (Zed) OS: Linux X11 debian unknown Memory: 251.5 GiB Architecture: x86_64 GPU: AMD Radeon Pro W6400 (RADV NAVI24) || radv || Mesa 24.0.6-1

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your Zed.log file to this issue.

Zed.log

[Amritraj015]

I've noticed this in C# files as well while using vim mode (on Fedora 38), after tapping the j key, it takes approximately 1 second for the cursor to move to the next line.

[osa1]

I've also noticed that this happens in other kinds of files as well. I've updated the issue description with a JS file where the same happens.

[ubirdio]

I'm noticing the same thing (navigation and typing) in python files. After minor edits to a python file, the editor grinds to a crawl on every/any file (python, json, md, etc). It saturates to 100% CPU usage during any text navigation/editing. It maintains 25-40% CPU usage when idle (previously it would sit around 5-10% instead).

I'm working on a top-spec macbook pro and Zed was previously instant.

I have tried disabling vim mode and the assistant, both make no difference.

Now looking to revert to an earlier version before this regression.

[ubirdio]

Unexpected insight: the slowness on my Zed is only present when the task-output panel is open. If I close it (e.g. cmd+J), we're back to normal speed. Navigation maxes out at 25% CPU and Zed sits at 1% CPU by default.

[osa1]

Unexpected insight: the slowness on my Zed is only present when the task-output panel is open

This is not what I'm observing, I don't use any of the panels.

Could admins remove the Dart label? Currently this issue looks like a Dart specific thing but it's not. I'm observing the same in JS files, and others reported the same thing in C#, Python, JSON, Markdown.

[Amritraj015]

Unexpected insight: the slowness on my Zed is only present when the task-output panel is open

This is not what I'm observing, I don't use any of the panels.

Could admins remove the Dart label? Currently this issue looks like a Dart specific thing but it's not. I'm observing the same in JS files, and others reported the same thing in C#, Python, JSON, Markdown.

I'm noticing the same thing, I don't have any panels open either and I still notice the sluggish navigation.

[SomeoneToIgnore]

If all of you are on Linux, I wonder if it could be related to https://github.com/zed-industries/zed/issues/14235 ?

When starting Zed with the outline already hidden, the performance is much better. After the outline is opened, the degraded performance reappears. From this state, hiding the outline wont fix the problem.

[osa1]

@SomeoneToIgnore it can't be the same issue, we (at least I and @Amritraj015) are not using any panels.

[ubirdio]

Unexpected insight: the slowness on my Zed is only present when the task-output panel is open

This is not what I'm observing, I don't use any of the panels.

Update: the panel issue makes every file sluggish. However, I'm still seeing a regression on large python files (thousands of lines) even with all panels closed. So there has been some other regression unfortunately.

[Amritraj015]

Update: I was able to figure out the root cause for my problem:

I was noticing sluggishness with my j key in normal mode while using vim mode, this prompted me to look at my key-binds and there was the problem... my j k key bind to switch to normal mode from insert mode (see the key bind below). After I removed this bind, the j key started responding much better.

    {
        "context": "Editor",
        "bindings": {
            "j k": ["workspace::SendKeystrokes", "escape"]
        }
    }

So, I guess the bug is, when the j (or whatever your first key is) key is pressed, the editor seems to be waiting for a period of time (approximately 1 second) to see if the k (or your second key) key is going to be pressed next. But, if the second is not pressed within this 1 second window, the editor seems to execute the action associated with the j key which in this case is to move the cursor to the next line after the window expires. This makes the editor feel unresponsive for 1 second after tapping the j key once.

I wonder if others on this post are facing the same problem???

[ubirdio]

Ah, that's different to my situation. Mine is the editor overall becoming sluggish (when typing, navigating, anything) and saturating the CPU core it's using.

[Amritraj015]

Update: I was able to figure out the root cause for my problem:

I was noticing sluggishness with my j key in normal mode while using vim mode, this prompted me to look at my key-binds and there was the problem... my j k key bind to switch to normal mode from insert mode (see the key bind below). After I removed this bind, the j key started responding much better.

    {
        "context": "Editor",
        "bindings": {
            "j k": ["workspace::SendKeystrokes", "escape"]
        }
    }

So, I guess the bug is, when the j (or whatever your first key is) key is pressed, the editor seems to be waiting for a period of time (approximately 1 second) to see if the k (or your second key) key is going to be pressed next. But, if the second is not pressed within this 1 second window, the editor seems to execute the action associated with the j key which in this case is to move the cursor to the next line after the window expires. This makes the editor feel unresponsive for 1 second after tapping the j key once.

I wonder if others on this post are facing the same problem???

I just went through the documentation again and realized that I had set up my key-bind incorrectly all along... It should have been set in the following manner based on: https://zed.dev/docs/vim

  {
    "context": "vim_mode == insert",
    "bindings": {
      "j k": "vim::NormalBefore"
    }
  }

But anyways, I haven't really tried navigating through a file with thousands of lines of code as of now, so I can't really say that I have the same problem but, I'll try that soon and see if I have the same problems as y`all.

Thanks!

[ubirdio]

Still happening on large files. Doesn't require the task panel to be open.

The editor will work normally on the large files for a while and then at some point become sluggish. Now it's at the point where as soon as I focus the editor window with that file open it jumps to 100-200% CPU usage. After defocusing the page it'll stay pegged for a while and then return to normal single-digit levels.

Very bizarre. Seems like some kind of complexity-leak where some data structure keeps expanding and a combinatorial explosion must occur. It seems to get worse when there is a parse error in the file (e.g. an unclosed multiline string). Perhaps it is something to do with the parsing error-path on large files.

[osiewicz]

I wonder if any of you have multiple diagnostics (warnings/errors) in the files you're trying to browse.

FWIW, I cannot reproduce the issue on https://github.com/tree-sitter/tree-sitter-python/blob/master/grammar.js with Zed Nightly and can reproduce it with Zed Preview. I recently landed a fix for file performance with many diagnostics in https://github.com/zed-industries/zed/pull/16824 and that grammar.js file has 500 errors (which would trigger the slowness this PR addressed). As for the repository that OP shared...

Thus, this might potentially be a duplicate of: https://github.com/zed-industries/zed/issues/16764

Let's see if tomorrow's Preview fixes the perf issues for y'all

[osiewicz]

The issue this PR attempted to fix scaled with number of diagnostic issues in a single file; I shouldn't have posted the total diagnostic count, as it's a bit misleading (though my line of thinking was that surely some of these 500k diagnostics must be in the current file - and 1k is enough to trigger the slowness).

[ubirdio]

Seems possible. My particularly slow file has >1000 diagnostics.

Odd that it seems to work fine for a while and then get slow.

[osa1]

The latest preview release fixed the issue for me.

[ubirdio]

Yep. With 0.151.1 navigating the file that was previously causing trouble is fine. CPU maxes at ~31%.

I also tested the "large unclosed multiline string" behaviour I noted in an earlier comment; it is also fine now. The language server node process does spike, but that's to be expected. The editor remains smooth.

Thanks!