panstromek

This is basically polymorphization, mentioned in the blog post. The prototype implementation is in progress.

I see, thanks. I assume `async-stripe` is auto-generated from some IDL, those crates sometimes bump into some pathologial pattern, I'll check it out.

`actix-web` itself should be fine, `sqlx` can be heavy if you use its compile time features, I'd assume `askama` is heavy as well, just based on the description (it generates rust code at compile time).

Otherwise it depends on how the code is structured (e.g. how generic it is, how deep types or complicated futures it creates).

Not sure if that's the name or a typo but I'm not gonna lookup that

I was also thinking about Move and Forget traits, which impact cancellation safety. I think those are at least somewhat soft-blocked on the solver, but I'm not sure. Honestly, you're probably much better contact to talk about that, this is out of my wheelhouse.

thanks, fixed ;)

> polymorphism

I assume you ask about polymorphization, which is a term used to refer to a specific optimization mentioned in the blog post.

The base version which Rust wants the most makes sense to enable by default for all builds, because it's purely just removing duplicate work - this is for cases like Vec<u64> and Vec<i64>, where we currently emit code for each one separately, even though it's pretty much the same for both.

More general version will make sense for debug builds or in some special cases, like when optimizing for size. I believe people also want to experiment with it for some interop use cases (and for that, it'd be useful to have source level annotation). I think it's too early to tell how all of this is going to look like, though.

20 minut definitely sounds suspicious. For comparison, Rust compiler takes ~10 minutes to build in release mode (in the simple config without all the fancy PGO stuff we run on CI).

Do you have some more info about the codebase, is it public?

I don't understandy why, but all submissions of this post so far had incorrect title. When I posted the correct one, it still got reassigned the wrong title and I had to edit it (and it didn't allow me to do that yesterday, only today).

It's deeper pipelining of the build units (similar to how CPU does pipelining). Rust has had pipelined builds for a while, but this extends it further.

We should ;)

Nice, excited to see that. This is basically deeper pipelining, IIUC. Nick (the author of the blog) implemented the current version of this "emit metadata sooner," optimization and already experimented with pushing it even sooner a while back.

We have discussed this briefly on last All Hands, the problem will probably be dealing with compiler errors, when they happen in builds that already emitted metadata. I believe this was the reason why it wasn't merged in the first place.

> there better support for incremental compilation

What do you mean by this?

btw. That could actually make it slower to compile. The compiler uses the orphan rule to short circuit some checks IIRC.

Nevertheless, people in the project are trying to figuring out a way to relax the rule while still maintaining coherence, so this might happen some day.