Exponential time complexity for parser combinator with RPITIT #132991
Labels
C-bug
Category: This is a bug.
E-needs-mcve
Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
F-return_position_impl_trait_in_trait
`#![feature(return_position_impl_trait_in_trait)]`
I-compiletime
Issue: Problems and improvements with respect to compile times.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
The
egglog
parser was recently rewritten from a generated parser to a parser combinator. One commit changed themap
combinator from a free function to a trait method (RPIT -> RPITIT), which caused a massive compile-time regression egraphs-good/egglog#468, going from a few seconds to 40s+.Adding a single no-op
map
increases compile time to 3m30s+More info in the repo: https://github.com/DaniPopes/egglog-rpitit-repro
@rustbot label +I-compiletime +F-return_position_impl_trait_in_trait
Meta
rustc --version --verbose
:Copy of README.md
Massive compile time difference between
RPITIT
"map" closure and a manually definedMap
struct that implements the traits.Extracted from
egglog
@ca52ac13cb3c0bbacc8e7cc540789521d1019bd2
. Issue: egraphs-good/egglog#468.Note that unboxed closures etc is not required, as seen in egraphs-good/egglog#470 this can be fixed on stable by changing the definition but I opted to use the nightly feature to make the diff smaller.
It can also be fixed by moving
map
outside of the trait.Reproduce:
On nightly:
On stable (with
RUSTC_BOOTSTRAP=1
):Output of
cargo rustc -- -Ztime-passes
:samply
profile: https://share.firefox.dev/3O7AzuOThe text was updated successfully, but these errors were encountered: