(Reducing) Mentat Binary Size

Thom Chiovoloni tchiovoloni at mozilla.com
Wed Jun 27 17:47:02 UTC 2018

On Wed, Jun 27, 2018 at 9:24 AM, Nicholas Alexander <nalexander at mozilla.com>

> Thom,
> <snip>
>> The next idea I had is that a lot of the libraries we import seem to
>> involve networking. The only network code we have is in `tolstoy`, which is
>> very experimental and not something we're planning on using in production.
>> Moving this to live under a `feature` flag reduces our size to 7396480
>> bytes, 4571776 bytes after strip.
> The WIP branch that Grisha and I are working on includes a "syncable"
> feature that does this, so we'll handle being able to avoid Hyper, etc in
> the very near future.  But thanks for the reminder!

Oh, yeah, that's a much more sensible name than actually exposing the
`tolstoy` name to consumers of mentat.

>> I also noticed a few libraries that had multiple versions built.
>> Specifically `regex` seems like it might be heavy (at the very least, it
>> has dependent crates), and we're building both 0.2 and 1.0.1 (the former is
>> specified by mentat_query_sql, and the latter by env_logger). Moving both
>> of these to be 1.0.1 brings the size down to 6565472 bytes, 4036968 after
>> strip.
>> (Worth noting that regex is a transitive dependency from `env_logger`,
>> which I suspect we aren't thrilled with, and the use of it inside
>> mentat_query_sql could probably be trivially rewritten
>> <https://github.com/mozilla/mentat/blob/master/query-sql/src/lib.rs#L567>
>> to avoid the dependency.)
> I filed a few issues rooted at https://github.com/mozilla/
> mentat/issues/772.  We should definitely cull `regex`, but `env_logger`
> is an application choice more than a Mentat choice.

Yeah. I mean, mentat probably shouldn't be depending on it though
(admittedly I'm not sure that we are outside of the CLI, or where we are if
so -- I haven't checked). If the application wants to that's fine. I also
suspect we want a different log configuration scheme for Android and iOS,
one that's more configurable at runtime. This is unrelated though.

>> There are probably other targets for this (the `memchr` lib seems to be
>> included twice, but while I've done exactly no checking, my gut says it
>> doesn't have the same heft as `regex`).
> Is it possible to estimate a size metric for each of our dependencies?
> Yes, it's difficult with LTO/inlining/dead code removal, but it would help
> gauge where to put effort.

Cargo-bloat <https://crates.io/crates/cargo-bloat> seems to do this. Note
that it seems to have a bug where it gives you the size of the binary
compiled to generate proc macros if you don't pass `--bin` though, which
I've filed on their bug tracker.

Here <https://gist.github.com/thomcc/38f832911ab11624fab0aa8dd472a516> are
my findings for it on the mentat cli (after the work documented in this
mailing list – for comparison this
<https://gist.github.com/thomcc/ef7090b6b9d3c5c202c7e79635f27d4a> is before
my fixes, which gives you some indication on things it's good at and not).
It also has a mode where it tells you which functions are responsible for
this (included), but it's mostly the same result here (in the
'before-fixes' version of this output there's a hint that we have two
`regex` crates in that the same functions appear more than once from it,
but that's about it – it would be nice if these were better called out but
oh well).

We might also want to try the tool it's based on, Bloaty McBloatFace
<https://github.com/google/bloaty>, which (presumably) has no rust-specific
support, but seems to have more features, such as giving size profiles more
types of libraries, breaking down which sections things are showing up in
(cargo-bloat only understands `.text`, although it does say how big the
non-.text part is), etc.

> Thanks for getting this started!
> Nick
NP, I enjoy digging into this sort of stuff.

- Thom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/sync-dev/attachments/20180627/d02337e2/attachment-0001.html>

More information about the Sync-dev mailing list