-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ignore certain files (i.e. all-packages.nix) #462
Comments
AFAIK my profiling data blames 'Document Symbol' for memory usage, for this file.
Not expected though.
Seems to be workaournds to add such 'option'. I think the correct solution is to 'reduce' the mem usage for such file, and reduce the file itself. AFAIK all-packages.nix has been proved to be bad practice in nixpkgs. All nix language servers have trouble with it! |
Does it comes from 'with'? Nixd consider all variables coming from
Did you mean semantic tokens or documentHighligjts? |
Hmm, that's curious; shouldn't document symbols be a one and done deal? I'd also expect them to be within an order of magnitude of the file they're based on but I'm observing a delta of 10000x.
Certainly. Such "dumb" escape hatches aren't necessarily a bad thing though.
Sure, that'd be great but the file will stay around for a little longer and will always be in the git history if you need to do historical digging. There is also the case of
Sure, I wouldn't expect any tooling to handle a dense code file in the megabytes without a hitch. Hence my desire to selectively disable tooling past certain limits. This is a tad more than just a little hitch though ;)
In the case of all-packages, yes, but in hackage-packages it comes from function args. I was able to make it grow memory uncontrollably by jumping to definitions in hackage-packages; it's very easy to repro.
What exactly do you mean by "BIG data"? The records for all top-level attrs of
How exactly does this one work? Does the LSP send over every instance that should be highlighted or is that up to the editor to decide? |
No, it should be flushed right after any text edits. I observed approximately 6GB memory usage, because the symbols in that file is such a large scale. That large memory consumption could be traced by "high" JSON encoding usage, because that request is much less inefficient in comparison to "semantic tokens".
Maybe I can introduce a new CLI flag which controls whether or not disable AST operations if it become apparently too large. (That's need to discussed).
Sadly LSP specification explicitly said it should be very "fuzzy" to highlight all "related". That's why I choose to send a full list of variables coming from same "with".
|
Hi @Atemu I think you may reduce the number of highlights in the response body? Would that solve your problem? To test this, you can fork this project and change the behavior here:
Read https://github.com/nix-community/nixd/blob/main/nixd/docs/dev.md#hack-nixd-from-source if you don't know how to setup the env :) |
Profiling: 2.8/3.0 GB comes from large document symbol information. |
So my Emacs has been hanging for a few seconds now because I hovered over
callPackage
inall-packages.nix
.Could nixd have the option to not enable LSP operations inside certain paths or past a certain file size?
Or is that something the editor's LSP client should implement? (joaotavora/eglot#1391)
This also affects nixd however as its memory usage balloons to many dozen GiB when I do this. When attempting to jump to a definition of some thing in all-packages always appears to add a few GiB to nixd' RAM utilisation. Is that expected?
The text was updated successfully, but these errors were encountered: