Consider making the references code lens opt-in

[SeeminglyScience]

Currently as long as you have code lens on you'll always get the references code lens. This can dramatically slow down very large workspaces.

A large portion of folks (anecdotal speculation) who try out VSCode have an existing workflow of "store all the scripts in this folder". This leads to them opening up their "all of my PowerShell" folder and coming away with the impression that VSCode's intellisense is slower than it otherwise would be.

We should add a new setting that controls this code lens specifically and have the default value be disabled until we can determine a better strategy to handle these workspaces without performance loss.

[JustinGrote]

We would want to make sure "go to reference", etc. would still work on an ad hoc fashion, albeit probably slower on first invocation. An ideal implementation would use file watchers and a cache too.

[SeeminglyScience]

Oof that's a good point. C++ has a UI for when it's searching references that makes it look mildly better than just stuck, we may want to look into how hard that would be.

[ili101]

I set "editor.codeLens": false in my setting when working with big PowerShell projects since 2020, this issue have some valuable information #2518 (comment) (@DarkLite1)

[JustinGrote]

"We could use a combination of file system watchers and caches to possibly increase perf here."
Looks like Tyler is of same thinking as me :)

[SeeminglyScience]

We do kinda do that already, just immediately instead of on demand.

[fenhl]

I'd like to see this since I find the references annotation distracting but would still like to use Code Lens features from outside this extension (specifically the shortcuts to resolve git merge conflicts).

[andyleejordan]

Resolved via #4139, #4170, and PowerShell/PowerShellEditorServices#1917.

[ghost]

Thank you for your comment, but please note that this issue has been closed for over a week. For better visibility, consider opening a new issue with a link to this instead.