Hacker News Reader

Comment by neobrain | Hacker News Reader

Unstripped, perhaps?

    ls -lh /nix/store/63rdpgbzn7f1smh7688crcrpfsh833bb-zed-editor-0.199.10/bin/zeditor
    -r-xr-xr-x. 2 root root 3.2M Jan  1  1970 /nix/store/63rdpgbzn7f1smh7688crcrpfsh833bb-zed-editor-0.199.10/bin/zeditor

EDIT: Ah, it was too good to be true. The true binary is hidden in libexec/.zed-editor-wrapped :(

    ls -lh /nix/store/52smrb1z8r4n71zx50xagkcdrhlga4y5-zed-editor-0.207.4/libexec/.zed-editor-wrapped
    -r-xr-xr-x. 2 root root 337M Jan  1  1970 /nix/store/52smrb1z8r4n71zx50xagkcdrhlga4y5-zed-editor-0.207.4/libexec/.zed-editor-wrapped

Extra weight also comes from webrtc, which nixpkgs dynamically links. So yeah, it's quite a large binary indeed.

View on HN

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.

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...

  $ 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.

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?

Reply on news.ycombinator.com