Skip to content

search: reduce bytes transferred for loading each search result by ~50-70%

Administrator requested to merge sg/optimize-highlighting into main

Created by: slimsag

This change makes it so that we only fetch the line ranges we actually intend to display as a search result, instead of fetching the entire syntax highlighted file for the result and then discarding all but the few lines we display for each match in it. This reduces the # of bytes transferred to the client by around 50-70% (roughly) and inherently the time it takes for search results to load especially when there is latency between the browser and Sourcegraph, since these requests are made as you scroll.

The actual change here is straightforward due to my prior refactor of this code in #16466

Depends on backend implementation: #16570

Reviewing: Ignore the first commit, its just a rename.

Feature flag

It is feature flagged behind enableFastResultLoading and off by default for the time being.

This is so that I can measure the before and after numbers as soon as I add monitoring via https://github.com/sourcegraph/sourcegraph/issues/16468 - in any case, I will turn this on-by-default in code before release on the 20th (it works really well, no reason not to.)

Measurements

As noted I will be performing more extensive measurements of the impact o this via https://github.com/sourcegraph/sourcegraph/issues/16468 - but here are some initial measurements based on browser network tools using a query like this on my dev instance:

error repo:sourcegraph/jsonrpc2 count:1000

It returns 173 matches across 9 files and the change is as follows:

  • Initial page load (50% reduction): 8kb before -> 4kb after
  • Scrolling through all results (70% reduction): 39kb before -> 12kb after

Numbers are compressed bytes of /.api/graphql?Highlight requests.

Since most matches per file are much lower in general than a generic term like error, it should help a LOT more than this in practice and especially in places where there is any fair amount of network latency between the browser and Sourcegraph.

Note: I plan to later investigate pre-loading some of the results, too, as part of the initial search HTTP query i.e. #16467 - that would help more with initial page load than this.

Helps #6992

Merge request reports