workspace/symbol extremely slow (~13s) to produce first result on a large-ish monorepo; especially poor experience w/ VScode's "Quick Open: Include Symbols"

[ELLIOTTCABLE]

Update: see first comment; this is due to search.quickOpen.includeSymbols.

Original content follows:

---

Type: Bug

My "Go to file" (⌃P) is extremely slow in the following situation:

1. Under VScode Remote - SSH;
2. in a largeish (~50,000 files; 1.6GB.) monorepo workspace;
3. with OCaml Platform enabled.

Video: https://imgur.com/M3QjVI3

(This doesn't reproduce with OCaml Platform disabled; and does reproduce with all other extensions disabled.)

It definitely seems to be something really slow with workspace/symbol; trying again with the 'trace' debugging enabled, I get this in the "OCaml Language Server" 'Output' pane:

[Trace - 7:15:00 PM] Sending request 'workspace/symbol - (1)'.
Params: {
    "query": "api.ml"
}


[Trace - 7:15:13 PM] Received response 'workspace/symbol - (1)' in 13322ms.
Result: []

I have observed other coworkers on the same codebase, however, (many of us use VScode + OCaml Platform) using a nearly-instantaneous ⌃P. Very jealous. :P

I'm not sure what's unique about my setup — coworkers (who do not observe this issue) and I share a remote, extremely beefy, devbox; although we each have a separate nspawn, separate clone of the codebase, separate configuration, etc. Nonetheless, I've been unable to clear this issue up by wiping out configuration, re-creating the workspace, re-cloning the project, etceteras …

Extension version: 1.12.2
VS Code version: Code 1.79.2 (695af097c7bd098fbf017ce3ac85e09bbc5dda06, 2023-06-14T08:58:33.551Z)
OS version: Darwin arm64 22.3.0
Modes:
Connection to 'ssh-remote+nspawn' could not be established
Connection to 'SSH: nspawn' could not be established Canceled
Remote OS version: Linux x64 5.16.0-0.bpo.4-amd64
Connection to 'ssh-remote+nspawn' could not be established

System Info

Item	Value
CPUs	Apple M1 Pro (10 x 24)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	13, 14, 15
Memory (System)	16.00GB (0.11GB free)
Process Argv	--crash-reporter-id ddb5da65-4654-412e-9dc3-738998ade011
Screen Reader	no
VM	0%

Connection to 'ssh-remote+nspawn' could not be established

Connection to 'SSH: nspawn' could not be established Canceled

Item	Value
Remote	SSH: nspawn
OS	Linux x64 5.16.0-0.bpo.4-amd64
CPUs	AMD EPYC 9554 64-Core Processor (256 x 3100)
Memory (System)	1510.76GB (1269.05GB free)
VM	0%

Connection to 'ssh-remote+nspawn' could not be established

[ELLIOTTCABLE]

Sigh. After spending an entire day trying to trace this down, it turns out it's a VScode setting that can be disabled:

"search.quickOpen.includeSymbols": false

---

I'll change the title, but this leaves the relevant request of the OCaml Platform team to basically be the much-more-open-ended 'improve first-result performance of the workspace/symbol request so it's not 13 seconds-to-first-result on large repos', heh. )=

Will have to report the underlying primary issue (… that Go To File doesn't show partial/filesystem results until the symbol request is complete!?) upstream!