gopls/internal/cache: avoid unnecessary mod tidy invalidation
When a file is closed (didClose) we get a transition from overlay
to disk which gopls always assumed was a "save" event that
invalidated mod tidy handle. That in hand triggered an unnecessary
"go mod tidy" invocation.
Browsing files in VSCode for example could cause a lot of didClose
event on unchanged files, and if the module is large each
invocation takes a while.
With this change we now check if the Identity changed when
determine if a file was saved, from the perspective of go mod tidy.
If the Identity hasn't changed, the content hasn't changed.
diff --git a/gopls/internal/cache/snapshot.go b/gopls/internal/cache/snapshot.go
index 75ac34a..3e50bb5 100644
--- a/gopls/internal/cache/snapshot.go
+++ b/gopls/internal/cache/snapshot.go
@@ -1999,6 +1999,16 @@
// are both overlays, and if the current FileHandle is saved while the original
// FileHandle was not saved.
func fileWasSaved(originalFH, currentFH file.Handle) bool {
+ if originalFH == nil || currentFH == nil {
+ return true // should not happen for valid file handles
+ }
+
+ // If the file identity has not changed, the content has not changed.
+ // Therefore, the "saved" state (from the perspective of go mod tidy)
+ // has not changed.
+ if originalFH.Identity() == currentFH.Identity() {
+ return false
+ }
c, ok := currentFH.(*overlay)
if !ok || c == nil {
return true
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
Failed check was to due flaky unrelated test (reproduced on master with "go test . -run TestCheckGoModDeps -count=10000 -failfast").
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +2 |
Thanks for this optimization. The change looks sound to me. It would be nice if we could have a test, but I don't see any precedent for an integration test that checks for internal server events (e.g. trace events, go command invocations, etc) whose presence or absence can be asserted as a side effect of a given sequence of client operations. cc'ing Rob in case he remembers one.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
gopls/internal/cache: avoid unnecessary mod tidy invalidation
When a file is closed (didClose) we get a transition from overlay
to disk which gopls always assumed was a "save" event that
invalidated mod tidy handle. That in hand triggered an unnecessary
"go mod tidy" invocation.
Browsing files in VSCode for example could cause a lot of didClose
event on unchanged files, and if the module is large each
invocation takes a while.
With this change we now check if the Identity changed when
determine if a file was saved, from the perspective of go mod tidy.
If the Identity hasn't changed, the content hasn't changed.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |