On Wed, Jun 27, 2018 at 9:24 AM, Nicholas Alexander <[email protected]> wrote:
> 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. <https://github.com/RazrFalcon/cargo-bloat/issues/22> 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
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
