3 ms·

Given the conclusion that a painfully large amount of time is spent re-evaluating procedural macros and that this was largely mitigated by adding a cache, it wo

by saurik 3y ago

Given the conclusion that a painfully large amount of time is spent re-evaluating procedural macros and that this was largely mitigated by adding a cache, it would seem as if the linked discussion about "const" macros on the Rust language design forum is incorrectly analyzing the near-term need for deploying such a feature: they are concentrating on security use cases (which frankly seem a bit dubious to me) or (this one I hadn't heard before but is in the thread) changing where they are packaged (which, to those of us in the peanut gallery wearing our separate compilation hats and prototype fan club hoodies, seems like a far-too-entrenched mistake in Rust's design to bother fixing at this level) whereas being able to safely and automatically know which macros can be cached and which ones can't be (particularly as I'd pray that the big listed use case from the article of a non-const macro--including a file as bytes--either already isn't slow or clearly should be trivially fixed to not be slow) seems to be the real banner feature of having const macros be standardized.

estebank 3y ago
Reading the article.made me realize that we could do something that might or might not be a net positive: we can assume that proc macros are idempotent and immediately use the cached version while still performing the compilation and expansion as we do now. If the result of the new run matches, then we mark the macro as "likely idempotent". If not, we mark it to never attempt to cache that macro for that crate version ever again (globally in a devs machine, even!) and invalidate all of the unitd that assumed idempotency. This would pessimize the incr comp performance for the first compilation the "optimization" fails, but would allow all other cases to compuke faster (with no resource utilization improvements). This approach doesn't require people to annotate their crates in any way. As an improvement on this approach we can add annotations for known non-idempotent crates to not bother with this new behaviour. All of this would get around the issue of "what if a crate is incorrectly marked as idempotent?".

by saurik 3y ago

estebank 3y ago

Reading the article.made me realize that we could do something that might or might not be a net positive: we can assume that proc macros are idempotent and immediately use the cached version while still performing the compilation and expansion as we do now. If the result of the new run matches, then we mark the macro as "likely idempotent". If not, we mark it to never attempt to cache that macro for that crate version ever again (globally in a devs machine, even!) and invalidate all of the unitd that assumed idempotency. This would pessimize the incr comp performance for the first compilation the "optimization" fails, but would allow all other cases to compuke faster (with no resource utilization improvements). This approach doesn't require people to annotate their crates in any way. As an improvement on this approach we can add annotations for known non-idempotent crates to not bother with this new behaviour. All of this would get around the issue of "what if a crate is incorrectly marked as idempotent?".