Skip to content

Compilation time blows up with huge, numerous and nested enums #42747

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

Closed
hadronized opened this issue Jun 19, 2017 · 5 comments
Closed

Compilation time blows up with huge, numerous and nested enums #42747

hadronized opened this issue Jun 19, 2017 · 5 comments
Labels
I-compiletime Issue: Problems and improvements with respect to compile times.

Comments

@hadronized
Copy link

hadronized commented Jun 19, 2017

I’m building a GLSL parser and hence have a very specific need for numerous, deeply nested enums. I added all the grammar symbols / tokens, and now the compilation takes more 20 minutes on my rustc 1.19.0-nightly (78d8416 2017-06-17), Mac OSX. The compilation passes point at the item-types checking pass – it takes roughly 5 minutes here – as being the bottleneck. The code can be found here.

Important note: I think that the problem is linked to all the numerous recursive enums. I guess rustc struggles to identify the size or whatever about the enums because it tries to see whether recursions are terminal? Thing is: I tried to box almost all variants, and the result is there: I reduced the compilation time from 20 minutes to a few seconds.

Extra note: you can take the module linked above and compile it directly with rustc, no need to depend on the whole phaazon/glsl project ;)

@arielb1
Copy link
Contributor

arielb1 commented Jun 19, 2017

@phaazon

First, if you have a big nested series of enums, you probably want to insert a few boxes inside. Otherwise you can waste a ton of memory in "dead" variants (I just had to add a few Boxes to rustc to shave off a 100MB of RAM). The -Z print-type-sizes option on a nightly compiler can help you make sure that variant sizes are sane.

However, that should not cause any blowups in item-types checking! item-types checking should not be aware of the layout of your types, so that certainly looks like a bug

I was not able to reproduce the bug - the code you linked to seems to have the boxes in place already, and I was not able to cause slowness by removing boxes myself. Could you post a version of the code that exhibits the bug?

@lqd
Copy link
Member

lqd commented Jun 19, 2017

@TimNN
Copy link
Contributor

TimNN commented Jun 19, 2017

I had a quick look with Instruments on macOS and it seems that most of the time is spend in a somewhat deeply nested call to is_representable.

@TimNN TimNN added I-slow Issue: Problems and improvements with respect to performance of generated code. I-compiletime Issue: Problems and improvements with respect to compile times. and removed I-slow Issue: Problems and improvements with respect to performance of generated code. labels Jun 19, 2017
@arielb1
Copy link
Contributor

arielb1 commented Jun 19, 2017

I've seen that function hot on the rustc profiles too. Now that I have an excuse, let's go around fixing it.

@hadronized
Copy link
Author

Yep, the version linked by @lqd is the one to blame (I fixed my code with boxes and forgot I didn’t provide a link via the commit hash – sorry!).

arielb1 added a commit to arielb1/rust that referenced this issue Jun 19, 2017
I could have made representability a cached query, but that would have
been added complexity for not much benefit - outside of the exponential
worst-case, this pass is fast enough already.

Fixes rust-lang#42747.
bors added a commit that referenced this issue Jun 21, 2017
Memoize types in `is_representable` to avoid exponential worst-case

I could have made representability a cached query, but that would have
been added complexity for not much benefit - outside of the exponential
worst-case, this pass is fast enough already.

Fixes #42747.

r? @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-compiletime Issue: Problems and improvements with respect to compile times.
Projects
None yet
Development

No branches or pull requests

4 participants