# Project/use line hint for search \(\#58871\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/9375695626f1bba18ae5ba3153aa200c999e342e)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: 9375695626f1bba18ae5ba3153aa200c999e342e

Requested commit: 9375695626f1bba18ae5ba3153aa200c999e342e

Commit: 9375695626f1bba18ae5ba3153aa200c999e342e

Tree: 2bdc77e5e59b2185cdb30fb77d3b60f1110e2bca

Author: mertkanakkoc

Committer: GitHub

## Message

```
Project/use line hint for search (#58871)

Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

This PR makes two changes:

1. detect() now returns the line number of the first match instead of
just a boolean.
2. This line number (line_hint) is threaded through the pipeline and
passed as a subrange to query.search in full buffer scan, so the full
buffer scan starts from where the first match was already found instead
of the beginning of the file.
 
 ## Scope

  - This optimization only applies to **local search** (not remote).
- It is only effective for **single-line text and single-line regex**
queries. For multiline queries, `detect()` returns `line_hint = 0`, so
the full buffer is scanned from the beginning as before.
- It does not apply to already-open buffers, which always receive
`line_hint = 0`.
  
  ## Test
i tried to search the word "typeably" in the file
"pkgs/development/haskell-modules/hackage-packages.nix" of the repo
[nixpkgs](https://github.com/NixOS/nixpkgs) given in the comment:
[comment](https://github.com/zed-industries/zed/issues/38799#issuecomment-4088491295).
Result seems promising:
 
**with line_hint: 
search: 45.21ms** 

**without line_hint:
search: 508.05ms** 

I measured the time within the function: "handle_find_all_matches"

## Assumption

The core assumption is: if the search query is long enough (after 4 or 5
chars), the probability of finding multiple matches in a single file is
low. In that case, re-scanning the content before line_hint is
unnecessary — detect() function already confirmed there is no match
there.
 
Changes maybe can make an improvement on issues #38799 and #58905

---------

Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
```

## Parents

- [b3d5ead59f39bdd7d5badf1a0a968522f960fa12](https://git.cafe/gitcafe/zed/commit/b3d5ead59f39bdd7d5badf1a0a968522f960fa12?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/9375695626f1bba18ae5ba3153aa200c999e342e?format=markdown)