The compiled binary is about 2MB of size. It might be good to have a look at the following document so we could get down the size, which might enable us to ship it with Firefox in the future. Here some tips and tricks: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html
Note that we probably have to look into this if we ever want to contemplate shipping geckodriver alongside Firefox in the official packages. But outside that specific scenario, it is likely not a big problem for users to download 2M. I hypothesize removing the slog and clap dependencies would significantly reduce the size of the binary. We only use the slog dependency because the official log crate doesn’t let you reinitialise the log level at runtime, and clap can easily be replaced by a few dozen lines of code.
OS: Unspecified → All
Hardware: Unspecified → All
Version: 57 Branch → Trunk
So the compiled binary size in central now is actually quite a lot bigger than 2M. Are you sure you didn’t look at the size of the (compressed) packages we distribute on GitHub? They are ~2M. I played around with some optimisation techniques I know about: central: 7.2M target/releasegeckodriver lto: 6.5M target/release/geckodriver lto + strip: 3.0M target/release/geckodriver lto + panic abort + strip: 2.7M target/release/geckodriver lto + panic abort + strip + nightly rust + opt-level "s" without CARGO_INCREMENTAL: 2.4M target/release/geckodriver lto + panic abort + strip + nightly rust + opt-level "z" without CARGO_INCREMENTAL: 2.3M target/release/geckodriver lto + panic abort + strip + nightly rust + opt-level "z" without CARGO_INCREMENTAL + musl static: 2.3M target/release/geckodriver If we compress the smallest of the binaries with basic gzip, we get a package that is roughly half the size of the current packages we distribute on GitHub: 952K geckodriver.tar.gz Of course, all this optimisation comes at the cost of increased compile time for optimised builds, no backtraces on panic, no debug symbols, having to use the nightly Rust compiler, and not having access to incremental compilation. I think the next logical step is to look at what crates we depend on that can be blamed for the bloated binary size.
I would say this is something we will want to look into if, indeed, we want to ship geckodriver with Firefox.
Severity: minor → normal
Priority: P5 → P3
You need to log in before you can comment on or make changes to this bug.