3 ms·

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.

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?

neobrain 1y ago
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.
- vga42 1y ago
  [dead]
- deleted 1y ago
  [deleted]
- johnisgood 1y ago
  $ 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.
  - neobrain 1y ago
    > 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.
    - johnisgood 1y ago
      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.
      - SSLy 1y ago
        Maybe some kind of "security" software interfering?
        deleted 1y ago
        [deleted]
  - deleted 1y ago
deleted 1y ago
[deleted]
johnisgood 1y ago
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.
andrewl-hn 1y ago
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.
- panzi 1y ago
  I read the question differently as: Why doesn't cargo cache (compiled) crates in ~/.cargo?
phplovesong 1y ago
This is pretty common for larger rust projects. Its basically the new javascript+npm mess, this time with a borrow checker.

neobrain 1y ago

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.

vga42 1y ago
[dead]
deleted 1y ago
[deleted]
johnisgood 1y ago
$ 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.
- neobrain 1y ago
  > 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.
  - johnisgood 1y ago
    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.
    - SSLy 1y ago
      Maybe some kind of "security" software interfering?
      - deleted 1y ago
        [deleted]
- deleted 1y ago

deleted 1y ago

[deleted]

johnisgood 1y ago

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.

andrewl-hn 1y ago

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.

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

phplovesong 1y ago

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