Improve extension_trait!
#1005
Improve extension_trait!
#1005
Conversation
They never run because they are subsumed by the two rules immediately above.
That way, when the `-> impl Future` rules fail (which is most of the time), the cost of reparsing the accumulated tokens is avoided.
|
Even with these changes the amount of compile time for |
There was a problem hiding this comment.
This is fantastic, thank you!
Even with these changes the amount of compile time for
extension_trait!is still significant. If it could be eliminated altogether, I estimate cargo check build times would drop by a similar amount again.
I would actually be open to this change as well. The reason why we introduced this macro in the first place was because we were keen on showing that an "async version of std" was actually possible and nearly 1:1 translatable.
It's been nearly 3 years since we first showed that to the world though, and the idea that that's indeed possible is mainstream now. In that regard the macro approach has served its purpose, and I think we could move off it now if we wanted to. Because the macro only ever changed docs, and not actual reachable paths, I don't think we have to consider it a breaking change even.
Either way, that's for the future. I appreciate you benchmarking the impact of the macro, and helping us improve compile times!
The
extension_trait!macro is an example of a "push-down accumulation" macro. Unfortunately, such macros are inherently quadratic to run, because the accumulated tokens must be reparsed for every recursive invocation. Some of theextension_trait!inputs are large -- the one insrc/stream/stream/mod.rsis over 2,000 lines. As a result, the compile time ofasync-stdis dominated by macro expansion.This PR adjusts
extension_trait!in a way that reduces its compile time without affecting its functionality. For acargo checkbuild of the leaf crate on my Linux box I saw compile time reductions of about 25%. The two commits both have roughly equal effect on compile time.