Poor search performance in large repositories

[bjackman]

Summary

Poor search performance in large repositories

Description

Using the linux kernel repo as an example. This is not particularly extreme but it's big enough that a dumb grep is unusably slow:

❯❯  time git grep vmx_l1d_should_flush
[...]

________________________________________________________
Executed in  826.73 millis    fish           external
   usr time    0.76 secs    985.00 micros    0.76 secs
   sys time    3.83 secs      0.00 micros    3.83 secs

❯❯  time grep -R vmx_l1d_should_flush .
...

________________________________________________________
Executed in   49.77 secs    fish           external
   usr time    8.49 secs  986.00 micros    8.49 secs
   sys time    9.32 secs   88.00 micros    9.32 secs

Timing Zed's project search for the string, (using my stopwatch on my phone), I find when I am connected to the server above via SSH (i.e. using Zed's remoting feature), the same search takes about 4s.

Doing the same search again locally on my laptop takes 559.40 millis with Git and about 3s with Zed.

I noticed when I first open the project in Zed, there's a Git process that hogs the CPU for a litle while. Combined with the fact that it's still much faster than a dumb grep, it looks like there's some optimisation working here, but it's just missing some trick or other.

With my stopwatch on my phone I measured about 4s to grep this repo in Zed. This is when remoting from a laptop with an Intel(R) Core(TM) Ultra 7 165U (Meteor Lake, 2023) into a high-spec GCP VM (some sort of Cascade Lake I think).

Steps to reproduce:

1. Have kinda decent laptop
2. Checkout https://github.com/torvalds/linux)
3. Use the project search

Expected Behavior: B L A Z I N G F A S T R U S T C O D E
Actual Behavior: Have to wait literally MILLIONS of microseconds for my search results
:

click to expand

settings:

{
  "ssh_connections": [ <REDACTED> ],
  "base_keymap": "VSCode",
  "vim_mode": true,
  "file_types": {
    "makefile": ["*.makefile"]
  },
  "show_whitespaces": "boundary",
  "soft_wrap": "editor_width",
  "use_smartcase_search": true,
  "cursor_blink": false,
  "auto_update": false,
  "telemetry": {
    "metrics": false
  },
  "wrap_guides": [80],
  "languages": {
    "Nix": {
      "show_whitespaces": "none",
      "tab_size": 2
    }
  }
}

Log:

2025-09-24T18:17:53+02:00 INFO  [zed] ========== starting zed version 0.204.5, sha 289a4a6 ==========
2025-09-24T18:17:53+02:00 INFO  [zed] Using git binary path: None
2025-09-24T18:17:53+02:00 INFO  [crashes] spawning crash handler process
2025-09-24T18:17:54+02:00 INFO  [extension_host] extensions updated. loading 6, reloading 0, unloading 0
2025-09-24T18:17:54+02:00 INFO  [gpui::platform::linux::platform] activate is not implemented on Linux, ignoring the call
2025-09-24T18:17:54+02:00 INFO  [crashes] connected to crash handler process after 100ms
2025-09-24T18:17:54+02:00 INFO  [crashes] crash handler registered
2025-09-24T18:17:54+02:00 INFO  [util] set environment variables from shell:/bin/bash, path:/usr/local/google/home/jackmanb/.nix-profile/bin:/usr/local/google/home/jackmanb/.local/bin:/home/jackmanb/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/lib/google-golang/bin:/usr/local/buildtools/java/jdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
2025-09-24T18:17:54+02:00 INFO  [gpui::platform::blade::blade_renderer] Initializing Blade pipelines for surface SurfaceInfo { format: Bgra8UnormSrgb, alpha: PreMultiplied }
2025-09-24T18:17:54+02:00 INFO  [zed::zed] Using GPU: GpuSpecs { is_software_emulated: false, device_name: "Intel(R) Graphics (MTL)", driver_name: "Intel open-source Mesa driver", driver_info: "Mesa 25.0.7-2" }
2025-09-24T18:17:54+02:00 INFO  [project::environment] using project environment variables shell launched in "/home/jackmanb/src/linux". PATH="/usr/local/google/home/jackmanb/.nix-profile/bin:/usr/local/google/home/jackmanb/.local/bin:/home/jackmanb/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/usr/lib/google-golang/bin:/usr/local/buildtools/java/jdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
2025-09-24T18:18:11+02:00 INFO  [language] downloading language server "clangd"
2025-09-24T18:18:11+02:00 INFO  [lsp] starting language server process. binary path: "/home/jackmanb/.var/app/dev.zed.Zed/data/zed/languages/clangd/clangd_21.1.0/bin/clangd", working directory: "/home/jackmanb/src/linux", args: []

Zed Version and System Specs

Zed: v0.204.5 (Zed)
OS: Linux Wayland debian unknown
Memory: 62.3 GiB
Architecture: x86_64
GPU: Intel(R) Graphics (MTL) || Intel open-source Mesa driver || Mesa 25.0.7-2

[ConradIrwin]

Thanks for reporting. I know we still have more to do on performance here (in fact I went searching for a duplicate to merge this with, but couldn't find one, so I guess this gets to be the tracking issue :D).

@osiewicz could this have been improved by yesterday's project panel updates?

[pftbest]

In my case the issue happens in this scenario:

1. Connect remotely over ssh
2. Have a linux repo extracted in some directory that is in the .gitignore of the parent git repo
3. Navigate to a subdirectory in the kernel with a small amount of files
4. Start search in such subdir (and also toggle "Search files ignored by configuration" because of step 2)

For me it takes 38 seconds to search anything in a subdir with 11 small files, which seems very broken. Searching the same via the terminal takes less than 10ms

Zed Version and System Specs

Zed: v0.206.6 (Zed)
OS: macOS 15.6.1
Memory: 16 GiB
Architecture: aarch64

[ConradIrwin]

Hmm, we currently search strictly in-order so we can be sure results show in the correct order. I wonder if this causes a problem?

Does the ripgrep version terminate after 10ms, or just show the results sooner?

[pftbest]

@ConradIrwin no, the rg command terminates immediately. I did some more testing and I think this bug is related to button "serach files ignored by configuration". If I disable this button then search takes around 1 second instead of 30 seconds. Maybe it tries to search some files outside of the specified search directory?

[ConradIrwin]

Definitely I'd expect that button to make it slow as it requires us to look in all files in the current directory (even those that are .gitignored like build targets and config output). The equivalent command with ripgrep would be rg --no-ignore config_.

One other thing ripgrep does that we might want to figure out is allow listing results in any order, currently we always want to show the results in the same order as we show the file paths in the sidebar. This makes it easier to navigate the search hits, but means we have to wait until all earlier directories have been scanned before showing results in later directories

[pftbest]

The equivalent command with ripgrep would be rg --no-ignore config_.

If you look at my screenshot you will see that I do pass -u flag to ripgrep which is a short hand for --no-ignore flag and it still runs in 5ms flat. Because the directory which I search in is very small, it only has 11 files 1kb each and does not contain any hidden or ignored files. However my full project which is open in Zed is more than 50GB in size and contains millions of files.

I don't think the order of results matters here at all, I think Zed ignores the Include: field which specifies the path it should search in. It probably disregards the Include: field completely, searches the whole 50GB project and only then filters the output based on Include: field. Since it takes 38 seconds to search, that is the only reasonable explanation I see here.

However if it does work like that, it would be an issue for all big projects, because it's a very common operation to search in some small subdirectory of a bigger project.

[bjackman]

Just to be clear though I think there is a totally general problem here, it's not just that searching subdirectories of large projects is slow, and totally independently of the "search ignored files" setting, Zed's search is orders of magnitude slower than e.g. VS Code.

FWIW I also don't care in the slightest about the order of results appearing. If they can be sorted post-hoc so they eventually show up in the same order as the file list that's nice I guess, but I am 100% OK with seeing results appear as and when they become available, even if that means I become aware of "later" entries before "earler" ones.

[ConradIrwin]

I think there's two things:

1. We're slower than we should be (600ms vs 3s)
2. The Include handling is super-busted (10ms vs 38s)

Both seem worth looking at

[ronanchilvers]

Just chiming in here - I work with large PHP codebase with vendor folders (gitignored) and I've been seeing similar problems. Project searches with vendor in file_scan_inclusions are orders of magnitude slower than searches where vendor isn't in file_scan_inclusions - near instantaneous vs 30+ seconds. However the latest release (0.207.3) seems to have improved search performance a lot. It now seems to be almost instantaneous for both cases! 🎉