Skip to content
This repository was archived by the owner on Sep 30, 2024. It is now read-only.

Performance: Lazy highlight search results#40263

Merged
lrhacker merged 9 commits intomainfrom
tr/lazy-load-search-results
Aug 17, 2022
Merged

Performance: Lazy highlight search results#40263
lrhacker merged 9 commits intomainfrom
tr/lazy-load-search-results

Conversation

@umpox
Copy link
Contributor

@umpox umpox commented Aug 11, 2022

Description

Adds lazy syntax highlighting to search results.

Note
There's room for more experimentation here. We could also:

  1. Do the highlighting on the client and only fetch LSIF data from the backend like we do here. Potentially faster, although building the HTML on the quick isn't particularly quick either
  2. Share the highlighting between the Blob page and the search results. If we have the highlight the entire file for a search result, then we shouldn't do it again when we then load that result in the blob. Perhaps we could share a query between these two views.

Before

LazySearchBefore3.mp4

After

LazySearchAfter2.mp4

Test Plan

Per the videos attached above, ensure the behavior is as expected in-app.

App preview:

Check out the client app preview documentation to learn more.

@cla-bot cla-bot bot added the cla-signed label Aug 11, 2022
@github-actions github-actions bot added the frontend-platform Issues related to our frontend platform, owned collectively by our frontend crew. label Aug 11, 2022
@umpox umpox linked an issue Aug 15, 2022 that may be closed by this pull request
@novoselrok
Copy link
Contributor

This is a tough trade-off, but I think the lazy highlighting solution is the better solution. The issue with including highlighted HTML in streaming search results is that it blocks all results until the first N results are highlighted. So if we get a huge file to highlight or the highlighting server has a slow day, we massively degrade the UX because we won't show anything. With that in mind, I feel it's better to show something rather than wait for the fully highlighted experience.

I tried out the PR locally, and search results feel significantly faster (because the local highlighting is so slow).

@lrhacker lrhacker marked this pull request as ready for review August 17, 2022 00:36
@sourcegraph-bot
Copy link
Contributor

sourcegraph-bot commented Aug 17, 2022

Codenotify: Notifying subscribers in CODENOTIFY files for diff b8398d8...511e551.

Notify File(s)
@fkling client/search-ui/src/components/CodeExcerpt.tsx
client/search-ui/src/components/FileMatchChildren.tsx
@limitedmage client/search-ui/src/components/CodeExcerpt.tsx
client/search-ui/src/components/FileMatchChildren.tsx
@philipp-spiess client/jetbrains/webview/src/search/results/SearchResultList.story.tsx
@vdavid client/jetbrains/webview/src/search/results/SearchResultList.story.tsx

@lrhacker lrhacker requested a review from novoselrok August 17, 2022 00:43
@lrhacker lrhacker merged commit f89593e into main Aug 17, 2022
@lrhacker lrhacker deleted the tr/lazy-load-search-results branch August 17, 2022 16:42
jdorfman pushed a commit that referenced this pull request Aug 17, 2022
* Initial

* Update to use new format arg

* Go

* Format

* Flag logic

* Rename variables to avoid confusion

* Additional PR feedback

* Improve date use in story to prevent snapshot failure

Co-authored-by: Laura Hacker <laura.hacker@sourcegraph.com>
philipp-spiess referenced this pull request Aug 22, 2022
…#40621)

A [recent change](https://github.com/sourcegraph/sourcegraph/pull/40263)
changed one of the GraphQL queries that the VS Code extension is using
to add a new field that was only recently added to the GraphQL backend
(c.f.
[here](https://sourcegraph.slack.com/archives/C01LZKLRF0C/p1660889509990719)).

This unfortunately is not available on "older" server versions including
`3.42.1`. This means that every person that updates their VS Code
extension release now and is on an on-prem server that lags a bit behind
will see the search broken.

We do not yet have a system to get the server version and make decisions
based on it so I decide to fix it by reverting to the previous query in
the VS Code environment (the backend is written in a way that it can
handle older clients, just not the other way around).
j-shilling referenced this pull request in j-shilling/cody-lsp-gateway Jun 20, 2023
… (#40621)

A [recent change](https://github.com/sourcegraph/sourcegraph/pull/40263)
changed one of the GraphQL queries that the VS Code extension is using
to add a new field that was only recently added to the GraphQL backend
(c.f.
[here](https://sourcegraph.slack.com/archives/C01LZKLRF0C/p1660889509990719)).

This unfortunately is not available on "older" server versions including
`3.42.1`. This means that every person that updates their VS Code
extension release now and is on an on-prem server that lags a bit behind
will see the search broken.

We do not yet have a system to get the server version and make decisions
based on it so I decide to fix it by reverting to the previous query in
the VS Code environment (the backend is written in a way that it can
handle older clients, just not the other way around).
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

cla-signed frontend-platform Issues related to our frontend platform, owned collectively by our frontend crew.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Performance: Investigate lazy syntax highlighting on search results

5 participants