didChangedWatchedFiles notifications lock up emacs on startup
#843
Comments
|
Try with ghcide HEAD, it should set much fewer watches |
|
@michaelpj I think that Since I only use a single workspace, I removed the check and let my single workspace process it unconditionally: (defun lsp--file-process-event (session root-folder event)
"Process file event."
(let* ((changed-file (cl-third event))
(event-numeric-kind (alist-get (cl-second event) lsp--file-change-type)))
(->>
session
lsp-session-folder->servers
(gethash root-folder)
(seq-do (lambda (workspace)
(with-lsp-workspace workspace
(lsp-notify
"workspace/didChangeWatchedFiles"
`((changes . [((type . ,event-numeric-kind)
(uri . ,(lsp--path-to-uri changed-file)))])))))))))Without this change, |
|
@mrBliss have you opened an issue with |
The reason I haven't is because I thought that mainly Also, I don't immediately see how |
|
The maintainers might have an idea! We should at least give them the opportunity to close it wontfix ;) At least it would be helpful to get a clear signal of "no really, don't do this", if that's the case. |
|
I made an issue anyway, let's see what they say. |
|
It doesn't seem to be better on newer versions of |
|
I've noticed some further odd behaviour. It seems like if we look at a file This renders emacs almost unusable for me after I've opened a few components. |
|
That is how it works indeed. To resolve imported modules, ghcide has to consider all the possible locations where that module could exist, including all the import dirs and file extensions. This is because Cabal/Stack cradles provide module targets that do not identify the path to the module. If you are lucky enough to be using a Bios cradle then do make sure to provide file targets; ghcide is smart enough to register only one watcher per file in most cases. Changing the current behaviour to watch entire folders instead of specific files should be relatively easy to do, but it's not something I am planning to work on since my editor can handle the current behaviour with no problem at all. |
Could you leave a few bullet points saying what you would likely try here? I might give it a go. |
|
You will need to modify the The current implementation registers a watcher the first time it is called for a file F. You want to replace that with a workspace-wide watcher for the file extensions in https://github.com/haskell/ghcide/blob/master/src/Development/IDE/Types/Options.hs#L61 The workspace-wide watcher should probably be registered by |
This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776.
This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776.
This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776.
This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776.
This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776.
This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776.
This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776.
This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776.
This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776.
* FileExists: set one watcher instead of thousands This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes #776. * Use fast rules only if it matches our watcher spec
* FileExists: set one watcher instead of thousands This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes haskell/ghcide#776. * Use fast rules only if it matches our watcher spec
* FileExists: set one watcher instead of thousands This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes haskell/ghcide#776. * Use fast rules only if it matches our watcher spec
* FileExists: set one watcher instead of thousands This prevents us from sending thousands of notifications to the client on startup, which can lock up some clients like emacs. Instead we send precisely one. This has some consequences for the behaviour of the fast file existence lookup, which I've noted in the code, alongside a description of how it works (I spent a while figuring it out, I thought I might as well write it down). Fixes haskell/ghcide#776. * Use fast rules only if it matches our watcher spec
I observed this in HLS 0.3.0.0, but I'm pretty sure this is a ghcide issue, since this seems to be where we send the notifications.
When I start up a session in my (not ridiculously large) project, we send ~3k
didChangedWatchedFilesnotifications to the client. This locks up emacs completely until they are all processed, which it seems to do slowly, at a rate of ~10 responses a second (by tailinghie.log).This is a pretty bad user experience. Clearly some of the fault is emacs' or
lsp-mode's: 3k files to watch is really not that much, and I don't know how it's dealing with them so badly. Maybe we can do something upstream.However, maybe we could do something to stress it out less. Some possibilities:
didChangeWatchedFilesnotification (it supports sending multiple watchers per notification). I suspect this would reduce the number of messages a lot.Foo.hsandFoo.lhsseparately, which could be merged.<src>/**/*.hsfor all the component's source folders might be an over-estimate, but it might be worth it if it's cheaper.The text was updated successfully, but these errors were encountered: