Closed quodlibetor closed 3 months ago
What does:
the current main doesn't actually start the client afaict
mean?
My only reservation here is the fact that "bollard" appears to be a pretty big dependency. It only adds 5% to the aarch64 release binary size which is pretty good given how big bollard is and how many dependencies it has. (2290952 bytes vs 2406648 bytes, on my machine. Good job, I guess, rust compiler!)
Still, I wonder if we can do it more cheaply?
Oh lol I was measuring on aarch64 which doesn't even include bollard because it doesn't talk to a docker daemon. Let me re-check on linux....
OK, on my linux box, running rustc 1.80.0 (051478957 2024-07-21)
with cargo build --release
:
This is a 66% increase in binary size. Can we do better?
Very fair, I'll check.
tl;dr fat lto seems to make the biggest difference, and I think running with this profile gets the best bang-for-buck:
[profile.small-s-strip_debuginfo-lto_fat]
inherits = "release"
strip = "debuginfo"
opt-level = "s"
lto = true
It gets fwd back down to 2,966,648 bytes (on current main (6335944) I get 1,843,880 with that profile, so the ratio stays the same but we're back to the same size). Docs for these options here.
I checked (rust 1.80) if disabling bollard's default features changes anything, and it doesn't seem like it:
fwd/target/x86_64-unknown-linux-gnu$ eza --long --no-time --no-user --bytes --sort size x86_64-unknown-linux-gnu/release/fwd-*
.rwxr-xr-x@ 5,029,536 release/fwd-no-default-features
.rwxr-xr-x@ 5,029,952 release/fwd-with-default-features
so I tried a few profiles, I ran:
for profile in $(rg -N -o 'small-[^]]*' Cargo.toml ) ; do
echo "building $profile" | tee buildlog
cross build --target x86_64-unknown-linux-gnu --quiet --profile "$profile" --bin fwd
done
and got:
$ eza --long --no-time --no-user --bytes --sort size x86_64-unknown-linux-gnu/*/fwd
.rwxr-xr-x@ 2,337,520 small-z-strip_symbols-lto_fat/fwd
.rwxr-xr-x@ 2,345,712 small-s-strip_symbols-lto_fat/fwd
.rwxr-xr-x@ 2,770,776 small-s-strip_debuginfo-lto_fat-codegen1/fwd
.rwxr-xr-x@ 2,966,648 small-s-strip_debuginfo-lto_fat/fwd
.rwxr-xr-x@ 2,966,648 small-s-strip_no_____-lto_fat/fwd
.rwxr-xr-x@ 3,096,720 small-z-strip_no_____-lto_fat/fwd
.rwxr-xr-x@ 3,655,400 small-_-strip_debuginfo-lto_fat/fwd
.rwxr-xr-x@ 3,940,072 small-z-strip_symbols-lto_no/fwd
.rwxr-xr-x@ 3,949,680 small-s-strip_debuginfo-lto_thin-codegen1/fwd
.rwxr-xr-x@ 4,690,608 small-s-strip_debuginfo-lto_thin/fwd
.rwxr-xr-x@ 5,029,952 release/fwd
.rwxr-xr-x@ 5,108,864 small-s/fwd
.rwxr-xr-x@ 5,843,992 small-z/fwd
with these profiles in Cargo.toml (based mostly on min-sized-rust):
[profile.small-z]
inherits = "release"
opt-level = "z"
[profile.small-s]
inherits = "release"
opt-level = "s"
[profile.small-z-strip_no_____-lto_fat]
inherits = "release"
opt-level = "z"
lto = true
[profile.small-s-strip_no_____-lto_fat]
inherits = "release"
opt-level = "s"
lto = true
[profile.small-_-strip_debuginfo-lto_fat]
inherits = "release"
strip = "debuginfo"
lto = true
[profile.small-_-strip_debuginfo-lto_thin]
inherits = "release"
strip = "debuginfo"
lto = "thin"
[profile.small-s-strip_debuginfo-lto_fat]
inherits = "release"
strip = "debuginfo"
opt-level = "s"
lto = true
[profile.small-s-strip_debuginfo-lto_thin]
inherits = "release"
strip = "debuginfo"
opt-level = "s"
lto = "thin"
[profile.small-s-strip_debuginfo-lto_fat-codegen1]
inherits = "release"
strip = "debuginfo"
opt-level = "s"
lto = true
codegen-units = 1
[profile.small-s-strip_debuginfo-lto_thin-codegen1]
inherits = "release"
strip = "debuginfo"
opt-level = "s"
lto = "thin"
codegen-units = 1
[profile.small-z-strip_symbols-lto_no]
inherits = "release"
strip = true
opt-level = "z"
oh but it'll be a few days before I can check what the actual performance of this is on the server, I've pushed up a commit that includes this profile in case you want to test.
I see you've also moved things around to make it easier to make things optional, would you like me to put the bollard dependency behind a docker feature?
If you could split out the different features into different PRs that would be great. I have a stab at another approach for querying docker I would like to try if you don't mind... I should know if it will work today, or if we want bollard...
I have pushed my version of docker support to the repository; do you think you could give it a try?
do you think you could give it a try?
I'll give it a shot but I'm gone for a week so it'll be a bit. The code looks reasonable, though. I mean, as reasonable as hand-writing a json parser can ever be 😂
See the individual commits for easier-to-review work.
This is based on an older commit because the current main doesn't actually start the client afaict.