Bug 17135 – Optimization of big functions takes a lot of time

Status
NEW
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2017-01-31T20:59:37Z
Last change time
2024-12-13T18:51:28Z
Keywords
backend, performance
Assigned to
No Owner
Creator
Nick Sabalausky
Blocks
21121
See also
https://issues.dlang.org/show_bug.cgi?id=21121
Moved to GitHub: dmd#19230 →

Comments

Comment #0 by bus_dbugzilla — 2017-01-31T20:59:37Z
I'm at a bit of a loss as to narrowing this down, but I've hit a case where compiling a project causes DMD to hang (but only when compiling in release mode). $ git clone https://github.com/Abscissa/SDLang-D.git sdlang $ cd sdlang $ dub test --build=release It will never reach the linking stage, and you can check in your system's process manager that DMD itself is hung with a spiked CPU utilization. If you omit the "--build=release" it will work fine. Maybe someone with better bisect-fu or dustmite-fu than I could get this narrowed down a bit?
Comment #1 by bus_dbugzilla — 2017-02-01T04:35:34Z
Forgot to include the relevent commit checkout: $ git clone https://github.com/Abscissa/SDLang-D.git sdlang $ cd sdlang $ git checkout 6b2097f6944 $ dub test --build=release
Comment #2 by ag0aep6g — 2017-02-04T20:05:11Z
1) Use dub's -v switch to get the dmd command. Then get rid of dub. From the dmd command, throw unneeded arguments away one by one; both switches and source files. Result: dmd -c -O -unittest -Isrc src/sdlang/lexer.d 2) Remove all unittests from lexer.d. Compiles quickly now. Check unittest blocks individually. It's the large one at line 1552. 3) Reduce that beast. Just delete from the end. Turns out when I delete just that last `stderr.writeln` part, compilation finishes in 14 seconds on my machine. If I leave it in, it takes forever. Huh. Seems that `if (numErrors > 0) writeln();` makes the optimizer take much longer. 4) Minimize the code of the unittest by generating many identical testLex calls. Delete almost all the rest of lexer.d. Result: ---- module sdlang.lexer; import sdlang.symbol; import sdlang.token; import sdlang.util; int numErrors = 0; void testLex(string source, Token[] expected) {} unittest { enum n = 110; import std.array: replicate; mixin( `testLex("", [ Token(symbol!"Value", Location.init, Value(0)) ]);` .replicate(n) ); import std.stdio; if (numErrors > 0) writeln(); } ---- That compiles in about 10 seconds on my machine. If I remove the writeln line, it compiles in under 2 seconds. Can make the ratio more extreme by increasing n. 5) Incorporate Token, Symbol, Location. Get rid of most of Phobos. Generally reduce. Final result: ---- int numErrors = 0; void testLex(Token expected) {} void writeln(); void main() { enum n = 110; import std.array: replicate; mixin( `testLex(Token(Symbol.init, Location.init));` .replicate(n) ); if (numErrors > 0) writeln(); } struct Token { Symbol symbol; Location location; this(Symbol symbol, Location location) {} } struct Location { ubyte[32] data; } /* The size of Location.data matters: * 8 bytes or less - problem much less pronounced, * 9 through 32 bytes (didn't check every number) - very slow optimization, * more than 32 bytes - problem much, much less pronounced. */ struct Symbol {} ---- Call that file file test.d. Delete everything else. Compile with `dmd -c -O test.d`. Takes about 10 seconds on my machine. Remove the writeln line in main and it takes under one second. Increase n to make the ratio more extreme. At n = 200, compilation takes 1m42s for me. Seems to be quadratic.
Comment #3 by dfj1esp02 — 2017-05-18T15:22:18Z
IIRC there was an issue about this - dmd backend optimization is quadratic on function size, though can't find it now.
Comment #4 by dfj1esp02 — 2017-05-18T15:23:59Z
*** Issue 17410 has been marked as a duplicate of this issue. ***
Comment #5 by ag0aep6g — 2017-05-18T15:29:11Z
(In reply to anonymous4 from comment #3) > IIRC there was an issue about this - dmd backend optimization is quadratic > on function size, though can't find it now. I remember issue 14571, but there it was the size of a fixed-sized array.
Comment #6 by johan_forsberg_86 — 2021-04-14T07:16:16Z
Is this still the case?
Comment #7 by ibuclaw — 2021-04-14T07:22:53Z
(In reply to Imperatorn from comment #6) > Is this still the case? There are still a number of quadratic loops in the backend, whilst they still exist, all bugs assigned to the meta issue 21121 are valid.
Comment #8 by robert.schadek — 2024-12-13T18:51:28Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19230 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB