Zed is no longer usable.

[solaeus]

I can no longer use Zed for my work or personal projects, nor can I recommend it to others.

Zed eats insane amounts of memory. Whether it's zed-editor itself or rust-analyzer, it is now a common, multiple-times-per-day occurrence for Zed to crash my system by consuming all of my memory. Other text editors can run rust-analyzer all day without using even a fraction of the memory it uses under Zed. Even when it does not crash, Zed consumes absurd amounts of memory even when it is just sitting idle displaying a couple of files. In order to use Zed, one must constantly contend with its memory issues.

Without a correctly-implemented memory model, Zed is just an experiment. It may be a fascinating toy, but it is not a viable product. I hope things swing back in the other direction because I've been a Zed daily driver and it can be great. But for now I need to get some work done without my editor crashing or freezing and Zed just cannot offer that.

After just a few minutes this:

Turns into this:

[SomeoneToIgnore]

Can you please share the way to reproduce this?

[solaeus]

The same problems happen in small repositories as well. It can just be 4 or 5 files with 1 open in the editor.

[SomeoneToIgnore]

Odd, I do work on this particular repo for over 3 years and had not experienced such thing ever, neither with small projects.
One guess could be the background scanner: if anything points to /, ~ or any large file tree, that will blow up, yet odd that you mention small projects too...

Could be Linux-specific though, as I use macOs mainly: given that you can profile memory with heaptrack, would you be able to capture one and share it?

We need something, a reproducer or a trace to make it actionable — happy to dig and fix it afterwards.

[solaeus]

heaptrack.zed-editor.353874.zip

Heaptrack uses zstd compression so I had to decompress that and recompress with zip to get it into a format I can attach on GitHub. Heaptrack can't decompress zip files on the fly, you have to decompress it into the data file then open that with heaptrack. I was only able to capture for 22 seconds. I had to make sure that heaptrack exited successfully to save its output while the system was actively running out of memory.

[SomeoneToIgnore]

Thank you for the data.

• Fist things first, was that a small project or Zed or any other?
  It seems reasonable to use the minimal-most possible project, ideally bare main.rs or lib.rs only project.
  Maybe, there's a very special combination of files that leads to this?

• Then, I seem to fail to see any GBs of memory leaked in the editor process (the sample does contain Zed-specific traces so this is the right app profiled):

If I'm mistaken somehow, would appreciate the pointer and explanation — otherwise, we need to dig deeper as it's not Zed itself and something else.

• Those stats in OP, how are they shown?
  If those aggregating all subprocesses, can you split them and see what's the biggest offender?
  Something like

• If it's the rust-analyzer process, it could be checked separately in the GUI or the system, what's its memory usage?

• What's in the logs, anything large and repeated like

?
Even if not, would be good to attach it and see, when the project is minimized enough: e.g. rust-analyzer's version is of a particular interest to me, could be that it's picked up oddly from the system somewhere.

• Another idea would be to try and open such problematic project in some non-regular place, e.g. ~/Downloads/ to see if anything FS-related could impact this.

---

As you see, I'm still pretty clueless and have no data to diagnose the issue.
Would be superb to get more info and capture where exactly those 22GB retain, if not in Zed per se...

[solaeus]

I'm going to work on a Rust project soon. I will try running Zed with heaptrack from the beginning to get the full story. I guess heaptrack can't really "snapshot" memory in an already-running process. It's not a tool I know well, I just had it on hand.

I can also dig into it in more detail if I catch it leaking but still have time before it eats everything.

[julio-sandino-zip]

Hello I recently started having RAM problems as well with Zed. It jumps to 40GB of RAM and then my system crashes. Was not dealing with this problem last week.
Zed 1.13.2
Commit: 5cdb7ab
Version: 1.13.2+stable.335.5cdb7ab9d9546db683132cfa78e68acec3064cac

Interestingly the problem only presents itself when I open the project in my docker dev container. Again i've been doing this for months and didn't have a problem but I do now.

edit: The memory usage spikes under normal utilization too.
OS: 7.0.0-28-generic #28~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Wed Jul 1 15:50:57 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

[anthonysette]

Just experienced this myself today, may be related to a new update and potentially a memory leak. Zed was using 130gb of memory which caused my Mac to pause all my applications and kill Zed to resume. Otherwise my computer would have crashed

[anthonysette]

Zed tried to consume 130gb of memory today. Had to force quite the application. Screams memory leak, potentially from a recent update since this is new.

[eminor1988]

I’ve run into the same issue. Usually, when I start a new AI agent conversation, memory usage stays stable at first. However, after the conversation reaches a certain point, something seems to get triggered, and memory usage suddenly starts increasing very rapidly. Restarting Zed and continuing the same conversation doesn’t seem to help, the issue still occurs.

What I usually do is pause the agent before it runs out of memory. At that point, it seems like garbage collection kicks in, and memory usage gradually decreases. Once it drops to a certain level, I resume the agent and let it continue processing. I end up repeating this process over and over.

[TaufiqSyed]

Had this exact same issue, took 12GB of memory on my 16GB RAM laptop, with a repository of just 3 markdown files with no AI running on it... Very odd

[SomeoneToIgnore]

I have to restate again that we are not able to reproduce the memory issues ourselves, and desperately need someone to provide us the intelligent insights, at least the reproduction steps if not the memory profiles — otherwise it's just impossible to act upon.

Meanwhile, I'm quite exhausted from all the context-less messages when there's the entire set of instructions posted above: #59303 (reply in thread) so will close and lock this thread so I won't get any useless messages like #59303 (comment)

There are already existing issues like #59402 and #59915 , or you can create another one and ping me if you have anything actionable on the topic.