What is costing so much ram in clojure-lsp? I have some clojure-lsp processes that take like 5 GB of ram, It's my bottleneck these days š
in the meantime š
Code analysis that come from kondo during startup, it depends how big is your project, you can tune to disable keyword analysis or symbols for example but that will disable features for those
so it's just at the beginning and then the jvm greedily hold on to the ram?
would be awesome if clojure-lsp was a unique process then š
clojure-lsp holds the data structures in memory
Also having a single process would not help that much as it would hold different projects data, summing everything in a single process besides being harder to manage, although its an old idea that it's not trivial to support
(I must admit I maxed out the RAM for my new machine with clojure-lsp in mind š )
yeah me too I'm really pissed my motherboard has issues with 256gb so I had to downgrade to 128gb and now it freezes but because I reache it all the time
128gb isn't enough...?
then clojure-lsp likely won't be the issue unless you have dozens of projects?
yes I do
Yeah, I have 16GB ddr5 and it's not a issue, you must be using multiple projects at the same time?
And I use 3-4 projects at the same time
damn emacs starting a lsp-sever every time I open a file in a project š
Sounds like misconfigured project root
Wow, that explains it
wdym misconfigured project root?
I can imagine that the fact that my main project is cloning some core libraries for facilitate editing the code adds up to how much it has to index?
If you open files of the same project, lsp-mode should use the same running server
no but it is the same project but different worktrees
Like a mono repo?
maybe try using a single clojure-lsp for the whole thing
no worktrees are like a branch but instead of checking out and screwing your current wip you go into a different directory
Just having a single project root with configured settings for other source paths, dunno, would need to understand better your arch
It's not clear yet to meet how your folders look like, if there is more than a deps.edn/project.clj etc
You could try lsp-remove folders
one oddity is that I clone multiple projects in a .local-repos to make it easier to read the source and edit it
that may explain the size of some lsp instances
one of the reasons I haven't really explored git worktrees is precisely this, as I would expect to get a LSP process per worktree. Just like if you checked out the same git repo multiple times into separate directories (e.g. for different branches) and then opened each as separate projects.
exactly and it kinda sucks because fundamentally there isn't much difference between 2 worktress, so with clojure immutable datastructure inner workings it could even be really cheap to have worktrees if it was natively understood by clojure-lsp
baically just the diffs
hehe unfortunately it's not that easy, but having a common project root would be the start for that
I would imagine efficiently constructing and sharing the analysis data between two arbitrary projects (be they similar worktrees of a single codebase or totally different projects) would be almost impossible š But sometimes I've naively wondered if the startup time could be improved by hashing the namespace tree and caching the analysis or parts of it.
The fun thing is: we already do that, we cache analysis by file hashes
@jacob.maine helped with that years ago, and helped a lot the performance
I noticed tho we only do that for external analysis https://github.com/clojure-lsp/clojure-lsp/blob/f555e4b89a1a3aa8aa9f66809f0d5e4dc034c61d/lib/src/clojure_lsp/startup.clj#L127, IIRC it was for consistency to avoid cache something of the project that might changed, but not sure that's something that would happen
if the infrastructure is already(?) there, I wonder how much work would it require to extend that to cover project files too? perhaps guarded by a setting so that users can opt-in, in case there are issues. we have thousands of namespaces in one of our projects, some of which haven't been touched in years (or decades), so it would be cool to see how much of an effect such caching might have.
yeah agree, we can explore that
fwiw, Iām using worktrees and have similar issues. The worktrees often share 99%+ code.