I just compiled "zed" with "cargo build --release" and not only did it pull >2000 dependencies, its size (executable file) is literally 1.4G. Debug is 1.2G.

  $ pwd
  /tmp/zed/target/release
  $ ls -lh ./zed
  -rwx------ 2 john john 1.4G Aug 28 17:10 zed

---

  $ dut zed/ | sort -h
   598M    0B   | | /- webrtc-sys-0a11149cbc74bc90
   598M    0B   | | | /- out
   598M    0B   | | |- webrtc-sys-090125d01b76a5e8
   635M  160M   | |   /- s-hal7osjfce-1h7vhjb-4bdtrsk93m145adnqs17i9dxe
   635M  160M   | | |- project-06kh4lhaqfutk
   641M  161M   | | /- project-1ulvakop54j8y
   641M  161M   | | | /- s-hal5rdrth3-0j8nxqq-d0wsc7qnin39797z4e8ibhj4w
   1.1G  1.1G   | | /- zed-ed67419e7a858570
   1.1G  1.1G   | |- zed
   1.3G  1.3G     | /- zed-64b9faeefdf3b7df
   1.3G  1.3G     |- zed
   1.4G    0B     |- build
   2.2G    0B   | |- build
   7.9G  1.4G     /- deps
   9.4G    0B   |- release
    14G  2.9G   | |- incremental
    19G  4.2G   | /- deps
    33G    0B   /- debug
    42G    0B /- target
    42G    0B zed

Summary:

  $ du -h ./target/debug/deps/
  20G     ./target/debug/deps/
  $ du -h ./target/release/deps/
  8.0G    ./target/release/deps/

  $ du -h ./target/debug/zed
  1.2G    ./target/debug/zed
  $ du -h ./target/release/zed
  1.4G    ./target/release/zed

This is on a whole new level of bloat; both with regarding to dependencies AND the resulting executable file(s) (EDIT: executable files are unstripped).

Any explanations as to why "cargo" does not seem to re-use libraries (dependencies) in a shared directory, or why it needs >2000 dependencies (that I see being downloaded and compiled), or why the executable file of the release mode is 1.4G unstripped while of the debug one it is less?

This is pretty common for larger rust projects. Its basically the new javascript+npm mess, this time with a borrow checker.

Cargo does the de-duplication, but only up to a point. If two packages request the same dependency with semver ranges that have a common overlap (say, `1.4` and `1.6`) then it will use a single package for both (say, `1.7.12`). But if they request semver-incompatible versions (`2.1` and `1.6`) then cargo will use both.

I read the question differently as: Why doesn't cargo cache (compiled) crates in ~/.cargo?

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.

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?

I suppose it has to do with how every Rust crate (including dependencies) gets statically linked into the final binary, and this leads to extremely large intermediate artifacts, even when many crates share common dependencies.

Or the fact that there is incremental compilation artifacts...

And of course the amount of dependencies. A single project might depend on hundreds of crates (quite common), each compiled separately with its own build artifacts. sighs.

What does a desktop text editor have to do with WebRTC?

Judging by this note in the docs: Collaboration features.

https://zed.dev/docs/development/freebsd#webrtc-notice

If they're going to implement every feature under the sun and include half of userspace to support it, they might as well build the whole thing on top of a browser.

vscode has entered the chat...

Amazon q is 100mb and that’s a cli app. Rust programs be huge.