Re:Zed is now available on Windows
by johnisgood on Thursday October 16, 2025 @04:23AM
(#45602791)
$ strip --strip-all ./target/release/zed
$ du -h ./target/release/zed
261M ./target/release/zed
$ strip --strip-all ./target/debug/zed
$ du -h ./target/debug/zed
482M ./target/debug/zed
Correct. It is still embarrassing, in my opinion.To make matters worse, it takes several minutes for Zed's window to appear on a cold start, whereas VSCode launches almost instantly.
[1] I am trying to measure it as we speak but it is taking quite a long time.
> Not to mention it takes minutes for the window of Zed to open, whereas VSCode is almost instant.
That one is interesting. It's much quicker for me, even cold starts are below 1s, and subsequent startups are basically instant.
Re:Zed is now available on Windows
by johnisgood on Thursday October 16, 2025 @04:29AM
(#45602843)
Cold starts are minutes, subsequent startups are much faster than VSCode[1].
I wonder why though.
[1] I have not measured subsequent launches of VSCode though, but Zed is relatively pretty quick after the initial launch.
Maybe some kind of "security" software interfering?
Probably due to treesitter modules for many languages compiled in. AFAK Treesitter's codegen is unfortunately a share nothing between different languages. So a dozen language parsers can easily cross upward of 200 MB.
Binaries for dynamic libraries of tree-sitter (usually compiled with C compiler) would be smaller than that. For example this [1] .so bundle for 107 different grammars is ~137 MiB.
Unless by "compiled in", some in-lining of the C code into Rust codebase is meant.
[1] https://github.com/emacs-tree-sitter/tree-sitter-langs/relea...
Re:Zed is now available on Windows
by johnisgood on Thursday October 16, 2025 @06:09AM
(#45603539)
Additionally, in any case, now I know what I have to do to free up some space. Get rid of Rust projects I built from scratch.
Maybe something like this to figure out what directories to delete:
# With dut
find . -type f -name Cargo.toml -printf '%h\n' | sort -u | xargs -r -d '\n' -I{} dut -s {} | sort -h
# With du
find . -type f -name Cargo.toml -printf '%h\n' | sort -u | xargs -r du -sh | sort -h
I found "websocat" and "ripgrep". Thankfully I got rid of everything else. ripgrep $ cargo clean
Removed 3411 files, 1020.2MiB total
websocat $ cargo clean
Removed 1726 files, 820.7MiB total
That said, ripgrep itself is only 5.0M.
Extra weight also comes from webrtc, which nixpkgs dynamically links. So yeah, it's quite a large binary indeed.