Open Bug 1392313 Opened 3 years ago Updated 7 months ago

Reduce size of geckodriver executable

Categories

(Testing :: geckodriver, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: whimboo, Unassigned)

References

(Depends on 1 open bug)

Details

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
Please note that there might have been a change with the Serde and hyper changes. As Alexei pointed out when I gave him a geckodriver nightly build (as build from CI) it's size is 3x smaller than the last official 0.21 release. At least that is for Windows binaries. See https://www.screencast.com/t/eOtq5ZFvsxv

Here an update of the compressed binaries for geckodriver with the new toolchain build task in place:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&searchStr=geckodriver&revision=7004b8779a36084c898634e5e31d8f406815d68a

-rw-rw-rw-@ 1 henrik staff 1592260 Aug 29 09:27 geckodriver-linux64.tar.xz
-rw-rw-rw-@ 1 henrik staff 1163340 Aug 29 09:27 geckodriver-mac.tar.xz
-rw-rw-rw-@ 1 henrik staff 1285701 Aug 29 09:28 geckodriver-win32.tar.bz2
-rw-rw-rw-@ 1 henrik staff 1237782 Aug 29 09:28 geckodriver-win64.tar.bz2

So for all the platforms we are down to about 1.5MB now!

I will leave this bug open for further investigations.

Excellent, the baseline is now the same across all platforms. That
unblocks further work on this bug to further reduce the binary
sizes.

Depends on: 1578428
You need to log in before you can comment on or make changes to this bug.