-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Compilation time much longer without optimizations enabled than with them enabled #13968
Comments
This is an interesting case. Thanks for the report! It's not specifically infinite loops. Looks like is triggered by any dead code. A simple The earliest version where I was able to reproduce this problem is 0.4.17 (with small adjustments - file level constants were not allowed back then). The one thing that stands out to me in the changelog for that version is this:
The fact is, on the CLI the optimizer is never truly disabled. We always run the peephole optimizer and jumpdest removal steps. It's only possible to disable it completely via Standard JSON. This step probably has something to do with the slowdown. It would be interesting to run this via Standard JSON with the whole optimizer disabled and see if this is the source of the problem. Also, could you check if this affects Overall, I'm not sure if we should classify this as a bug. I'm inclined to say so, but if it's jumpdest remover, it could just have been designed with the assumption that such pathological dead code is already removed when it runs. @chriseth, what do you think about all this? By the way, the contract Test {
function test() public {
return;
v5;
}
} On my machine this still takes ~2s with dead code, but finishes almost instantly (~100 ms), with |
Thanks for taking a look at this @cameel. I can produce a measurable difference in execution time using your version of the code and standard json input with the following settings:
It seems like both the peephole and jumpdest optimizations need to be enabled to cause the issue. One thing I didn't mention in the initial report is that it seems like the compile time is increasing non-linearly with the amount of dead code. Very roughly, doubling the amount of dead code increases the compile time by 3x-4x. For example, adding another
I set
|
This issue has been marked as stale due to inactivity for the last 90 days. |
Hi everyone! This issue has been automatically closed due to inactivity. |
Description
The program below takes a long time to compile without optimizations enabled, but is very quick with optimizations enabled. This seems like odd behaviour and may suggest something weird going on in the compiler.
As the comments in the program suggest, this seems to require a statically detectable infinite loop. Furthermore, the expressions that impact the compilation time must come after this infinite loop. The requirement for a statically detectable infinite loop potentially limits the scope of the impact, however, it does seem like odd behaviour.
Environment
The text was updated successfully, but these errors were encountered: