Compile time

[tschuett]

I just tried the aws-sdk-ec2 in my workspace. rusoto_ec2 was always the second to last crate and took forever (66s) to build. aws-sdk-ec2 seems to be even worse.

>  cargo +nightly build -Z timings

aws-sdk-ec2 v0.0.8-alpha | 95.8s
rusoto_ec2 v0.46.0 | 66.5s

Is compile time something you are going to consider in the future?

[rcoh]

yeah this is definitely on our radar. Thanks for flagging it.

Other folks: please 👍🏻 this issue to prioritize compile times if they become an issue for you.

[tschuett]

You could add a demo example that depends on all SDKs for compile times measurement.

[jdisanti]

We kind of get that right now through the CI in smithy-rs where one of the actions compiles every single SDK as a single Cargo workspace. For example, the cargo test AWS SDK step, which currently shows 14 minutes for all of the supported services. This data gets muddied every time we add a new service though. It would be nice to have it split out by service so that we could, for example, compare EC2's compile time across builds. It would also be nice to track with cargo llvm-lines for a measurement that is less impacted by differences in the CI hosts.

[webern]

This is also my biggest complaint in using the SDK. One idea that a team member here had is that EC2 functionality could be opted-into using Cargo features. Often you will be using only a few calls from the API, but you have to compile all of it.

Another idea would be to use dynamically dispatched trait objects instead of trait bound generics. I don't know how much that wouldn't help, but I mention it because Rust for Rustaceans mentions faster compile times as a benefit of using dynamic dispatch.

[Velfi]

I've investigated this a teeny bit and at least part of the problem seems to stem from the fact that EC2 has a significant number (118) of paginated APIs. The paginators return impl tokio_stream::Stream which means we're doing a good amount of monomorphization. We'll investigate feature gating pagination or switching to dynamic dispatch.

[blaenk]

For my purposes I actually switched off of using this SDK to instead using a thin wrapper around the AWS CLI and shaved off many many minutes of build time, especially when you consider the separate rebuilds involved for e.g. tests/clippy/release.

Obviously this it not an option or ideal in most cases where the SDK is used, I'm simply sharing the difference it made for me.

I would love to use the SDK instead but for my light purposes it wasn't worth the cost of many minutes of build time.

I sincerely believe that it would be a great idea to get in touch with the Rust compiler optimization team about the compile times incurred by these crates because I think it would serve as a great case study and benchmark on the impact of e.g. monomorphization and optimizing that would benefit the broader Rust ecosystem.

[rukai]

We'll investigate feature gating pagination or switching to dynamic dispatch

Did anything come of these investigations?

For a short term fix I am considering forking the generated ec2 crate and removing all the code that is unused by my project.
Edit: i attempted stripping out the bits I didnt need but I've given up because of how entangled the generated code is.

[johnm]

I think we were all expecting at least some progress on this before this crate went 1.0. :-(

Any plans to event start addressing this issue?

[webern]

i attempted stripping out the bits I didnt need but I've given up because of how entangled the generated code is.

I think what is needed is for the code generation to include a bunch of feature gates on EC2 API functionality so that we can enable the things we need in Cargo.toml.

[gahooa]

Compile times of an async cli application went from 5 to 15 seconds just by referencing aws-sdk-ec2, and calling 2 different areas of the functionality.

I also was expecting some progress on this before Stable release, please address this asap.