Investigate build bloat

[dherman]

A friend told me about this recent article on Rust build sizes, and specifically the article links to a useful tool: cargo-bloat.

We should use that tool to see if there are places we can reduce the binary size of Volta builds (and possibly the build times as a consequence).

One particular hint I got was that reqwest is an especially large library, and there are competitors like isahc that are considerably smaller. We'd have to investigate to see if it looks like a good tradeoff, though (in terms of feature set, quality, level of maintenance).

And generally let's keep our wits about us—smaller binary size is good, but not if it comes at too high of a cost. It's not the only goal.

[joshuarli]

@dherman I briefly looked into this after building volta for myself and getting kind of mad at how long it took to compile everything. In particular, parking_lot has quite a large dependency tree, and it can be completely omitted from the build by:

• upgrading console and indicatif to 0.8.0 and 0.12.0 respectively, which removes their hard dependency on parking_lot
• upgrading reqwest to 0.10.0, which upgrades hyper to 0.13, which upgrades tokio to 0.2.x, which makes parking_lot an optional internal dependency

The latter is the hard part because the hyper-011 feature in reqwest is removed in 0.10.0, so everything in #267 needs to be ported to new reqwests and it isn't AFAICT as trivial as a revert.

I doubt doing this will help binary size but it'll at least noticeably reduce the build time. It would also be nice to finally update these libraries.

[joshuarli]

There's also https://github.com/algesten/ureq if volta's willing to trade async http(s) for a significant boost in simplicity and correctness, I'd wager it would be worth it.

Or, https://github.com/sbstp/attohttpc. See https://users.rust-lang.org/t/lightweight-alternative-for-reqwest/33601/18.

[charlespierce]

Thanks for all that investigation @joshuarli! We actually don't use async http at all, everything is synchronous AFAIK. We've looked at rustls-based crates in the past, but there are still some outstanding questions around the maintenance of the underlying implementations that need to be investigated before we move off of OpenSSL.

As for upgrading reqwest to avoid parking_lot, we'd need to investigate that as well, since parking_lot claims to be a smaller implementation, so presumably moving off would lead to an increase in binary size (though it's possible, maybe likely, that we're already using std::sync::Mutex as well somewhere, so switching may actually reduce the binary size anyway).

[joshuarli]

If everything's indeed synchronous then the largest binary size (and compilation time) win would definitely be to move to pure non-async - of the two I mentioned above, it looks like attohttpc can do TLS via openssl: https://github.com/sbstp/attohttpc/blob/master/Cargo.toml#L42

[joshuarli]

Not very good at rust but I can probably take a stab at looking more into attohttpc. I did a shitty attempt in trying to upgrade reqwest but it got a bit convoluted, haha.

[charlespierce]

We'd definitely take a PR swapping to a smaller HTTP client! I took a look several months back at switching to isahc as a POC, and IIRC it did work, but as you said, it did get convoluted. Feel free to reach out if you run into any snags or need some more context on what we're doing with reqwest right now ⚡

[joshuarli]

Would you happen to stil have that branch lying around? Could be useful reference for me. If not, that's okay.

[charlespierce]

I don't, sorry 🙁 I'm not sure if I finished the work or got part-way in and decided it wasn't worth the extra effort, but it seems like I didn't ever push it up.