File search via @ symbol is very slow in large projects, possibly due to lack of debounce and search triggering on every character

[vpckso]

Describe the bug:

When using the "@" symbol to search for files in large projects, the search functionality is extremely slow and unresponsive. This significantly impacts the development experience and productivity.

Expected behavior:

The file search should be responsive and provide quick results even in large codebases, with proper debouncing to avoid excessive processing on every keystroke.

Actual behavior:

• Searching for files with "@" in large projects is very slow
• The search seems to trigger on every character input without proper debouncing
• UI becomes unresponsive during search operations
• Performance degrades significantly as project size increases

Additional context:

It appears that the file search functionality may not be implementing proper debouncing, causing it to execute search operations on every keystroke. In large projects, this results in multiple rapid-fire search requests that create performance bottlenecks and make the feature unusable.

Consider implementing:

1. Proper debouncing
2. Optimizing file search algorithms for large codebases
3. Caching mechanisms to improve response times

Environment:

• OS: Linux
• OpenCode Version: 0.11.3

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• File search with @ doesn't work properly after the first message #2345: File search with @ doesn't work properly after the first message
• Application Response Delay – Very Slow Processing Despite Stable Network #2704: Application Response Delay – Very Slow Processing Despite Stable Network
• Significant response time degradation over last releases #2684: Significant response time degradation over last releases
• Improve searching for files with long names #2416: Improve searching for files with long names

Feel free to ignore if none of these address your specific case.

[vpckso]

The problem seems resolved after upgrade 0.11.4?

[anmorgunov]

Still very slow at 0.12.1

[rekram1-node]

Hmm @anmorgunov can you tell me more about your project? How big is it and what language(s)?

[anmorgunov]

Actually it's pretty tiny (a new project), just 14 files (python).

I narrowed the issue a bit:

• the search is decently fast when I open opencode for the first time
• if, however, I have some coding session (using supernova / zen), then open a new session with /new w/o exiting opencode, it'll be excruciatingly slow.
• exiting opencode and entering it again resolves the issue.

lmk if there are other details that can be useful

[rekram1-node]

hmm that is weird ill see if I can replicate

Edit: @anmorgunov I found the issue, we don't have any timeout for symbol lookups and the python lsp is either taking too long or has some bug, there also doesn't seem to be any debounce setup properly here so if this is really painful you can use the following as a work around for now but I hope to have this better addressed soon.

Put in your opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": {
    "pyright": {
      "disabled": true
    }
  }
}

[anmorgunov]

@rekram1-node this works for now, thanks!

[R44VC0RP]

This issue appears to be resolved in current versions.

What was fixed:

1. Workspace symbol lookup disabled - The LSP workspace symbol lookup that was causing slowness (particularly with pyright) has been disabled. The @ file search now uses only the fast fuzzysort-based file index.

2. Memory leak fixes - Several memory leak fixes have been merged since this issue was reported, addressing the progressive slowdown when using /new within a session.

If you're still experiencing slowness, you can disable specific LSP servers via opencode.json:

{
  "lsp": {
    "pyright": {
      "disabled": true
    }
  }
}

If anyone is still experiencing file search slowness on recent versions (v1.1.x), please open a new issue with repro steps. Thanks!