4 ms·

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/

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]
lenkite 1y ago
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.
- pooyamo 1y ago
  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/releases https://github.com/emacs-tree-sitter/tree-sitter-langs/relea...
johnisgood 1y ago
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.

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]

lenkite 1y ago

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.

pooyamo 1y ago
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/releases https://github.com/emacs-tree-sitter/tree-sitter-langs/relea...

johnisgood 1y ago

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.