6 ms·

First off, the display looks great! Second off, I didn't realize how deep the dep tree would be for this type of program -- 141 total! So much of it is the url

First off, the display looks great! Second off, I didn't realize how deep the dep tree would be for this type of program -- 141 total! So much of it is the url crate, itself a dep of the git crate, but there's a bunch of others too. I'm just getting into learning Rust -- is this typical of Rust projects or perhaps typical of TUI projects in general? (EDIT to strikeout) ~~The binary is also 53M as a result whereas /usr/sbin/tree is 80K on my machine -- not really a problem on today's storage, but very roughly 500-1000x different in size isn't nothing.~~ Maybe it's linking-related? I don't know how to check really. (EDIT: many have pointed out that you can run `cargo build --release` with other options to get a much smaller binary. Thanks for teaching me!)

CGamesPlay 1y ago
Likely needs features tuned. I compared Eza, similarly in Rust, and it's 1.6 MiB compiled. Looking at the Cargo.toml, it includes git2 with default-features = false. https://github.com/eza-community/eza/blob/main/Cargo.toml https://github.com/eza-community/eza/blob/main/Cargo.toml
fabrice_d 1y ago
You are probably looking at a debug build. On Linux, a release build (cargo build -r) is ~4.3M, and down to ~3.5M once stripped. This could be reduced further with some tricks applied to the release build profile.
pveierland 1y ago
Building in release: cargo build --release du -sh ./target/release/lstr -> 4.4M Building with other release options brings it down to 2.3M: [profile.release] codegen-units = 1 opt-level = "s" lto = true panic = "abort" strip = "symbols"
- cyann 1y ago
  I did some benchmarks on one of our CLI and found that `opt-level = "z"` reduced the size from 2.68M to 2.28M, and shaved 10% on the build time, worth a try. I'll try with `panic = "abort"` for our next release, thanks for the reminder.
JoshTriplett 1y ago
> The binary is also 53M That's a debug binary, and the vast majority of that is debug symbols. A release build of this project is 4.3M, an order of magnitude smaller. Also, compiling out the default features of the git2 crate eliminates several dependencies and reduces it further to 3.6M. https://github.com/bgreenwell/lstr/pull/5 https://github.com/bgreenwell/lstr/pull/5 https://github.com/rust-lang/git2-rs/pull/1168 https://github.com/rust-lang/git2-rs/pull/1168 Stripping the binary further improves it to 2.9M, and some further optimizations get it to 2.2M without any compromise to performance. (You can get it smaller by optimizing for size, but I wouldn't recommend that unless you really do value size more than performance.)
- esafak 1y ago
  No offense, but 4.3MB is huge for what it does. Most shells take less space than that! Where's all the bloat coming from?
  - have-a-break 1y ago
    I feel like that's just the result of having a native package manager making natural bloat and a compiler which hasn't had decades of work.
  - o11c 1y ago
    For reference, some statically-linked shells on my system: 2288K /bin/bash-static (per manual, "too big and too slow") 1936K /bin/busybox-static (including tools not just the shell) 192K /usr/lib/klibc/bin/mksh 2456K zsh-static For comparison, some dynamically-linked binaries (some old) 804K ./bin/bash-3.2 888K ./bin/bash-4.0 908K ./bin/bash-4.1 956K ./bin/bash-4.2 1016K ./bin/bash-4.3 1092K ./bin/bash-4.4 1176K ./bin/bash-5.0 1208K ./bin/bash-5.1 1236K /bin/bash (5.2) 124K /bin/dash 1448K /bin/ksh93 (fattest when excluding libc!) 292K /bin/mksh 144K /bin/posh 424K /bin/yash 848K /bin/zsh (The reason I don't have static binaries handy is because they no longer run on modern systems. As long as you aren't using shitty libraries, dynamic binaries are more portable and reliable, contrary to internet "wisdom".)
  - 1y ago
ethan_smith 1y ago
Try `cargo build --release --no-default-features` to get a much smaller binary (~5-10MB) - Rust statically links dependencies but supports conditional compilation for optional features.
- aystatic 1y ago
  Glancing at the Cargo.toml, the package doesn't define any features anyways. `cargo b --no-default-features` only applies to the packages you're building, not their dependencies -- that would lead to very unpredictable behavior
getcrunk 1y ago
Great catch! Comments mentioned getting it down to ~2MB but that’s still humongous. If you just think about how roughly (napkin math) 2MB can be 100k loc, that’s nuts
- arlort 1y ago
  Is It though? You won't get it on an embedded device (maybe) but you could install a thousand of these tools and barely even notice the space being taken up on most machines
  - getcrunk 1y ago
    I think that’s a lame argument. First because it’s kind of a fallacy. Size is absolute not relative to something. Especially for software. No one thinks of software size primarily in the context of their disk space. Further I think everyone keeps getting larger and larger memory because software keeps getting more and more bloated. I remember when 64gb iPhone was more than enough (I don’t take pictures so just apps and data) Now my 128 is getting uncomfortable due to the os and app sizes. My next phone likely will be a 256
    - dotancohen 1y ago
      So bloated software is motivating you to spend more for the larger capacity phone? What incentive does Apple have to help iOS devs get package sizes down, then?
    - hnlmorg 1y ago
      I’m usually the first to complain about bloat but your counterpoints to the GPs “lame arguments” are themselves, fallacies. > First because it’s kind of a fallacy. Size is absolute not relative to something. Especially for software. No one thinks of software size primarily in the context of their disk space. That’s exactly how most people think about file sizes. When your disk is full, you don’t delete the smallest files first. You delete the biggest. > Further I think everyone keeps getting larger and larger memory because software keeps getting more and more bloated. RAM sizes have actually stagnated over the last decade. > I remember when 64gb iPhone was more than enough (I don’t take pictures so just apps and data) Now my 128 is getting uncomfortable due to the os and app sizes. My next phone likely will be a 256 That’s because media sizes increase, not executable sizes. And people do want higher resolution cameras, higher definition videos, improved audio quality, etc. These are genuinely desirable features. Couple that with improved internet bandwidth allowing for content providers to push higher bitrate media, however the need to still locally cache media.

CGamesPlay 1y ago

Likely needs features tuned. I compared Eza, similarly in Rust, and it's 1.6 MiB compiled. Looking at the Cargo.toml, it includes git2 with default-features = false. https://github.com/eza-community/eza/blob/main/Cargo.toml https://github.com/eza-community/eza/blob/main/Cargo.toml

fabrice_d 1y ago

You are probably looking at a debug build. On Linux, a release build (cargo build -r) is ~4.3M, and down to ~3.5M once stripped. This could be reduced further with some tricks applied to the release build profile.

pveierland 1y ago

Building in release: cargo build --release du -sh ./target/release/lstr -> 4.4M Building with other release options brings it down to 2.3M: [profile.release] codegen-units = 1 opt-level = "s" lto = true panic = "abort" strip = "symbols"

cyann 1y ago
I did some benchmarks on one of our CLI and found that `opt-level = "z"` reduced the size from 2.68M to 2.28M, and shaved 10% on the build time, worth a try. I'll try with `panic = "abort"` for our next release, thanks for the reminder.

JoshTriplett 1y ago

> The binary is also 53M That's a debug binary, and the vast majority of that is debug symbols. A release build of this project is 4.3M, an order of magnitude smaller. Also, compiling out the default features of the git2 crate eliminates several dependencies and reduces it further to 3.6M. https://github.com/bgreenwell/lstr/pull/5 https://github.com/bgreenwell/lstr/pull/5 https://github.com/rust-lang/git2-rs/pull/1168 https://github.com/rust-lang/git2-rs/pull/1168 Stripping the binary further improves it to 2.9M, and some further optimizations get it to 2.2M without any compromise to performance. (You can get it smaller by optimizing for size, but I wouldn't recommend that unless you really do value size more than performance.)

esafak 1y ago
No offense, but 4.3MB is huge for what it does. Most shells take less space than that! Where's all the bloat coming from?
- have-a-break 1y ago
  I feel like that's just the result of having a native package manager making natural bloat and a compiler which hasn't had decades of work.
- o11c 1y ago
  For reference, some statically-linked shells on my system: 2288K /bin/bash-static (per manual, "too big and too slow") 1936K /bin/busybox-static (including tools not just the shell) 192K /usr/lib/klibc/bin/mksh 2456K zsh-static For comparison, some dynamically-linked binaries (some old) 804K ./bin/bash-3.2 888K ./bin/bash-4.0 908K ./bin/bash-4.1 956K ./bin/bash-4.2 1016K ./bin/bash-4.3 1092K ./bin/bash-4.4 1176K ./bin/bash-5.0 1208K ./bin/bash-5.1 1236K /bin/bash (5.2) 124K /bin/dash 1448K /bin/ksh93 (fattest when excluding libc!) 292K /bin/mksh 144K /bin/posh 424K /bin/yash 848K /bin/zsh (The reason I don't have static binaries handy is because they no longer run on modern systems. As long as you aren't using shitty libraries, dynamic binaries are more portable and reliable, contrary to internet "wisdom".)
- 1y ago

ethan_smith 1y ago

Try `cargo build --release --no-default-features` to get a much smaller binary (~5-10MB) - Rust statically links dependencies but supports conditional compilation for optional features.

aystatic 1y ago
Glancing at the Cargo.toml, the package doesn't define any features anyways. `cargo b --no-default-features` only applies to the packages you're building, not their dependencies -- that would lead to very unpredictable behavior

getcrunk 1y ago

Great catch! Comments mentioned getting it down to ~2MB but that’s still humongous. If you just think about how roughly (napkin math) 2MB can be 100k loc, that’s nuts

arlort 1y ago
Is It though? You won't get it on an embedded device (maybe) but you could install a thousand of these tools and barely even notice the space being taken up on most machines
- getcrunk 1y ago
  I think that’s a lame argument. First because it’s kind of a fallacy. Size is absolute not relative to something. Especially for software. No one thinks of software size primarily in the context of their disk space. Further I think everyone keeps getting larger and larger memory because software keeps getting more and more bloated. I remember when 64gb iPhone was more than enough (I don’t take pictures so just apps and data) Now my 128 is getting uncomfortable due to the os and app sizes. My next phone likely will be a 256
  - dotancohen 1y ago
    So bloated software is motivating you to spend more for the larger capacity phone? What incentive does Apple have to help iOS devs get package sizes down, then?
  - hnlmorg 1y ago
    I’m usually the first to complain about bloat but your counterpoints to the GPs “lame arguments” are themselves, fallacies. > First because it’s kind of a fallacy. Size is absolute not relative to something. Especially for software. No one thinks of software size primarily in the context of their disk space. That’s exactly how most people think about file sizes. When your disk is full, you don’t delete the smallest files first. You delete the biggest. > Further I think everyone keeps getting larger and larger memory because software keeps getting more and more bloated. RAM sizes have actually stagnated over the last decade. > I remember when 64gb iPhone was more than enough (I don’t take pictures so just apps and data) Now my 128 is getting uncomfortable due to the os and app sizes. My next phone likely will be a 256 That’s because media sizes increase, not executable sizes. And people do want higher resolution cameras, higher definition videos, improved audio quality, etc. These are genuinely desirable features. Couple that with improved internet bandwidth allowing for content providers to push higher bitrate media, however the need to still locally cache media.