Typescript Mono repo's & pnpm (speed & cpu)

[KpjComp]

Summary

Zed, feels really fresh & clean editor, and for quick editing of files, like nixos configuration files etc works really well. Speed is certainly there.

But one major issue is using it for large mono-repos with Typescript, it takes lots of ram, eg, 21 Gig+ ram before I quit, so no idea what it would have finished at, and CPU cores on a 24 core CPU got pegged @ 33%. For an editor designed with speed in mind, this does not help.

Steps to trigger the problem:

Open a large Typescript mono-repo, with node_modules populated with pnpm, might do the same for npm, but I use pnpm.

Opening the same mono-repo in VS-Code does not exhibit this behaviour.

Actual Behavior:

Large amounts of Ram & CPU usage

Expected Behavior:

Less amounts of Ram & CPU usage

Some notes, I do remember VS-code at one point having the same issue with mono-repos, I've a feeling it was likely that each project in the mono-repo it's parsing all the node_modules again, even though the majority would be sym-links to the same node_modules it's already visited, aka. eg. lets say you have 10 projects in a mono-repo, and those 10 projects reference each other, and if the LSP parser is not de-duping the visits, thatch 10 factorial visits = 3628800 instead of just 10. IOW: I don't think the LSP is taking sym-linked node_modules as one entity. Of course it's not normal for all projects to reference all projects, but was just an example of how not de-duplicating the LSP visits will add up. And of course I didn't even include 3rd party node_modules in each of those projects too that would likely be duplicated between projects.

It would be really nice if this got fixed, as currently I'm unable to use Zed for Typescript projects, as because of the memory & CPU problem, VS-Code is currently way faster (a bit ironic). :)

Zed Version and System Specs

Zed: v0.161.2 (Zed)
OS: Linux Wayland nixos 24.11
Memory: 62.6 GiB
Architecture: x86_64
GPU: llvmpipe (LLVM 18.1.8, 256 bits) || llvmpipe || Mesa 24.2.8 (LLVM 18.1.8)

Note: yes, currently not using vulkan on this PC, but the same happens on my other PC with a better graphics card, 4070ti.

[noahtallen]

Wanted to plus one this, though in my experience, VS Code / Cursor are also very poor with TS language performance in massive repositories (with npm). To be fair, poorly written internal types can cause issues with tsc, and tsc itself is pretty bad with performance, but these are massive production projects and it's not always possible to have perfectly performant types.

One major way this pops up is jump-to-definition -- for example if the TS language server craps itself, extremely simple jump to definition doesn't work any more, such as a function imported from a neighboring file. (Also a problem in VS Code)

[probably-neb]

Thanks for reporting. TS LSP performance is definitely a problem. Going to close as duplicate of the existing issue talking about this.

If you have an open source example of a large monorepo like you described that ends up using large amounts of memory, I'd love if you shared a link in the other issue so that we can take a look and see if there's anything we can do on our end :)

[KpjComp]

@noahtallen -> "repositories (with npm)"

That's interesting, with pnpm I'm not having speed / memory issues and this is with a very large mono-repo. Memory usage about 250Mb, jump to definitions instant, even all the way into deeply nested dependencies. The only issue I have seen recently is the paths options in tsconfig confuses it, but relative paths are fine. I will be submitting an error report for this on TSC, as I kind of like been able to do project imports like -> import grid from "~/grid", paths within the same project here still work, but fail across mono-repos.

But I do have my theories why npm might have issues, npm node_modules flattening is very complex and will duplicate package installs, something pnpm avoids totally. But with pnpm and symlinks, TSC as default then detects duplicate sym-links as been the same entity. There is an option in tsconfig -> "preserveSymlinks", I've a feeling if I did that in a pnpm mono-repo I would have similar issues too.

[KpjComp]

@probably-neb

Unfortunately it's not a public repo. But if I get some free time, I'll see if I can knock up a quick demo and put on GitHub. If my theory is correct on sym-link de-duplication not working, I've a feeling it won't be too hard to create.

[probably-neb]

Sounds good. Be sure to tag me directly so I get notified when you post please :)