Reduce size of geckodriver executable

NEW
Unassigned

Status

Testing
geckodriver
P3
normal
8 months ago
18 days ago

People

(Reporter: whimboo, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 months ago
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
Priority: -- → P5
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
Depends on: 1442253
You need to log in before you can comment on or make changes to this bug.