Real time search

[JaLnYn]

Changed the action to initiate search to be keypress. Changed ReadyChunk size 1024 -> 4. However this slows down the editor. I'm looking for suggestions on how to proceed.

Possible solution includes implementing some sort of dynamic ReadyChunk that doubles in size. Changing the operation to O(n) -> O(logn)

There also doesn't seem to be caching or optimization for subsequent searches based on previous results.
Can implement some sort of search state?

Nucelo library could potentially solve this (and potentially increase the speed of your current searches)

Closes parts of #8279

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @JaLnYn on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[JaLnYn]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[SomeoneToIgnore]

However this slows down the editor.

This is too generic to be actionable.
How exactly does it make the editor slow? Can you capture any traces and share them?
Without any details, it's hard to make any suggestions on how to proceed.

Also, I feel that before solving
#20436

all this does not make any sense.

[JaLnYn]

I'm not sure how to capture traces. Is there instructions on this?

#20436 seems to be the same issue I'm having where I have stuttering when the list is updating.

Some observations:
Stuttering always starts small and increases as the list of matches increases.
When I increase the readychunk size, it seems to decrease the stuttering.

This would seem to suggest its something to do with rendering or loading the matches.
I will try the dynamic ready_chunk thing to see if this aleviates the issue.

Theres no error messages except for

[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8
[2024-11-29T15:20:12-05:00 ERROR project] stream did not contain valid UTF-8

[SomeoneToIgnore]

I'm not sure how to capture traces.

In this case I will close the PR, sorry, but the complexity of this issue is not in throwing some code together, but in the perf analysis and fixes.
Given that you are not sure about this process, this PR will be in the queue for quite some time which is not necessary.
Also, we have obvious issues with the project search we need to solve beforehand.

Related to trace capturing, here's a brief instruction I've composed for macOS: #19022 (comment)

For Linux, I'd start with man perf, but overall, the idea is the same.

This would seem to suggest its something to do with rendering or loading the matches.

I think it's even worse, this is more related to the fact that Zed opens and reads each file entirely + starts an LSP server (or reports the file being open, which triggers diagnostics pushing, analysis, etc.) for every new file that had a search hit registered.
So this is beyond rendering.