Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

⚠⚠⚠ Extreme compile times ⚠⚠⚠ #36

Open
martin-t opened this issue May 22, 2019 · 2 comments
Open

⚠⚠⚠ Extreme compile times ⚠⚠⚠ #36

martin-t opened this issue May 22, 2019 · 2 comments

Comments

@martin-t
Copy link

martin-t commented May 22, 2019

As the grammar gets large, compile times grow a lot. A grammar similar to C but still a lot simpler takes about 2 or 3 minutes to compile and it gets recompiled on any change to the project. I had to put it in a separate crate to avoid it. Expressions with many precedence levels seem to be the main cause but even without them it takes way too long.


Not sure if related but doc tests also seem to take ages when using plex and a large grammar.

@goffrie
Copy link
Owner

goffrie commented Jun 16, 2019

Yeah, this is a bit unfortunate. I believe the main issue is with compiling in debug mode. In particular, lalr is really slow without optimizations, so processing the grammar takes a long time. If you compile in release mode, you'll probably notice that part get faster... but then your own project will also be compiled in release mode, so it takes longer too. Using something like rust-lang/rust#48683 might work, though.

@martin-t martin-t changed the title Extreme compile times ⚠⚠⚠ Extreme compile times ⚠⚠⚠ Sep 25, 2021
@martin-t
Copy link
Author

Maybe this would help:

[profile.dev.package."*"]
opt-level = 3

Not sure, can't test, just remembered the plex issue when i learned about this.

Anyway, i think this issue should be pinned so people know what to expect - IMO plex is just not ready for production - any reasonable sized grammar will take way too long to compile and this is impossible to figure out before getting to that stage so i don't want more people to fall into the same trap. I put some warning signs on the issue name so it's easier to notice for now ;)

I really like the lib, it has the cleanest syntax of all i could find, there's just no way to be productive given the compile times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants