Investigate possible reduction on job scheduling on workspace/didChangeWatchedFiles

[radeksimko]

Context

Currently, as per LSP spec, as interpreted by maintainers - and more importantly - implemented by VS Code language client, the client will send both textDocument/didSave after saving a file and also workspace/didChangeWatchedFiles.

workspace/didChangeWatchedFiles is normally expected to deal with situations where files change outside of the IDE, such as when user runs git checkout branch-x, runs any other tooling which mutates the underlying FS tree, or simply edits files manually outside of that one IDE (e.g. uses a different IDE).

The most likely reason a client will send workspace/didChangeWatchedFiles alongside textDocument/didSave even if the content has not changed is because the metadata on the saved file has changed (i.e. modification timestamp was updated).

Unfortunately, the spec does not allow us to differentiate between metadata changes and content changes. Currently we pessimistically assume these are always content changes and run various jobs with the same assumptions, possibly wasting resources on re-computing things we already know.

Proposal

Investigate whether it's worth computing and comparing checksums in order to avoid re-computing things for the same version of a document/module.

Computing and comparing checksums may potentially be expensive on its own, so this will require some careful consideration, perhaps use of the OTEL data to ensure we're not just replacing one bottleneck with another.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.