High RAM usage of 680MB without plugins and an empty project #3132
Comments
timmywongcool
added
the
C-bug
|
Lapce Version: 0.3.1 System information I am having the Same problem, using 790 mb memory while i open a normal rust project |
|
I have the same issue. Lapce is taking 3.9 GB for a project VS code only took 1.1 GB to open. No plugins installed. Yes it's a big project, but if Lapce is less efficient than an Electron App, I'm not sure what the point of using Lapce is.
Update: I left Lapce running after observing the 3.9 GB usage with the project directory open, but no files open. The memory usage continued climbing until it reached 14.5 GB at which point I killed it. Seems like it is leaking memory, as this is pathological behavior. Lapce 0.3.1 |
Could you post some proof or details that could help investigate that? |
|
Proof: I reopened Lapce. It automatically opened the same project folder. I didn't open any files. Memory usage started going up steadily. Here are successive screenshots.
This seems to be a very repeatable problem, I'm happy to upload any diagnostic files Lapce generates if you can direct me to them. |
|
Can you unfold the |
|
|
|
Here's the logs folder. They seem unremarkable. |
|
How long does it take to reach 10GB+ of memory usage? |
|
I'm not precisely sure. 5-10 minutes. When I was watching, it appeared to be allocating around 50MB/second I'll try to time it |
No need, was just asking to get a rough estimate how quickly you can reproduce the issue, I'll add more logging around the parts I think that can cause the issue, but in the meantime could you verify with nightly release if the same things happen? |
|
Memory usage of nightly build is holding steady at around 290 MB |
|
I spoke too soon. I left it running in the background while I worked on other things. It just hit 18GB WTF is an idle Lapce process even doing to use this much memory? |
|
Update: I have a memory dump of the 18GB process. I obviously can't share it both for size constraints and NDA reasons. However, if there is any summarization analysis I can perform, I can post those results (eg a heap analysis summary). The project directory I'm opening has 70,000 directories and 532,172 files (some of which are build artifacts) |
|
Here's the output of !uniqstack in WinDbg after loading the 18GB dump file which hopefully gives you an idea of what the process was doing while the memory usage was high. |
Is it a single git workspace? |
Yes. A random sample of 30 byte subsequences from the 25GB dump showed a large fraction (40% to 50%) contained path names from the opened directory. Searching for a few arbitrarily chosen paths showed them repeated multiple times, sometimes 100s of times. While that can't be everything, 500k file paths of 100 bytes copied 100 times in the heap gives 5 GB. |
|
More back of the envelop math: If those 100 copies of 100 byte file paths were instead represented as 100 8 byte pointers to a single 100 byte path string, each path takes only 900 bytes to store instead of 10000 dropping the total memory required to store 500k paths to 450mb which is much more tolerable. Still begs the question why Lapce needs to load the path name of every file in the working directory (and at least in the current implementation store 100 copies of it). |
|
More heap analysis facts that may be helpful: 8.9 GB of the 25GB dump are "path like strings" (names separated by '/'), 8.1 GB of these start with the prefixes 'src', 'refs', or 'remotes'. Many of these path strings are replicated 1000s of times. 8.2 GB consists of strings matching file or directory names in the working directory |
|
Seems like it's mostly bloated due to git repo size |
|
Could you share how many remotes, branches, history are you keeping in that git workspace? |
|
There are only 114 refs under The repo is large, but VS code easily opens it never getting over 1G. I think the real issue is the massive replication of path strings on the heap. I cannot fathom what kind of useful processing requires keeping 1000s of copies of a path on the heap in memory. If I deduplicate the path strings extracted from the heap dump (eg run through |
|
Real numbers from a different lapce dump running against the same large project. strings extracted via |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Lapce Version
Lapce Version: 0.3.1
System information
Mac OS: 14.0
Chip: M1 Chip
RAM: 16GB
Describe the bug
Right after I open an empty (clean-slate) Lapce application, I see a high RAM usage of 680MB. I don't have any plugins installed and Lapce is freshly installed. My project itself is empty and I have not yet written a single line of code yet so I find it a bit strange that Lapce is consuming such high memory.
Additional information
Any thoughts on why this might be the case?
The text was updated successfully, but these errors were encountered: