Bug 2396 – -O causes very long execution time on foreach loop of large array of structs

Status
RESOLVED
Resolution
FIXED
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2008-10-06T14:28:59Z
Last change time
2019-09-09T15:03:05Z
Keywords
bounty, performance
Assigned to
Walter Bright
Creator
Steven Schveighoffer

Attachments

IDFilenameSummaryContent-TypeSize
275badstructliteral.dfile to demonstrate bugtext/x-dsrc594586

Comments

Comment #0 by schveiguy — 2008-10-06T14:28:59Z
While porting Tango to D2, I've found the attached file (modified to compile under phobos) doesn't finish compiling in a reasonable amount of time (a.k.a never). The data table is from the Tango locale package, I stripped out the struct only so there isn't any real tango code, just data. If I compile the file without -O it compiles in 6 seconds, which seems reasonable since it's 600k of data. If you comment out most of the lines in the table, it compiles quickly. As you add lines back in, the runtime seems to grow exponentially (not scientifically verified). This file compiles fine with -O under dmd 1.x, Here's a list of dmd2 compilers that I had on my system to try out: 2.015, 2.016, 2.018: also fails 2.006, 2.007: works Note that in 2.006 and 2.007, it compiled much quicker with -O (.3 seconds) than without -O using the compilers that fail (6 seconds)
Comment #1 by schveiguy — 2008-10-06T14:31:27Z
Created attachment 275 file to demonstrate bug
Comment #2 by schveiguy — 2008-10-06T16:15:10Z
BTW, this isn't exactly a blocker for Tango/D2, but in order to get it to work, I have to hand-compile the file, as the build-script uses -O for all Tango files.
Comment #3 by bugzilla — 2008-10-07T03:23:10Z
Pulling out part of the loop body as a separate function or nested function should work as a workaround.
Comment #4 by clugdbug — 2011-06-23T03:41:47Z
On DMD2.053 and later, the literal needs to be declared with 'enum' rather than 'static const' to expose the bug. It's slow because in this case, there is a single expression consisting of 14013 comma expressions, and several places in the backend use algorithms which are in O(commadepth ^^ 2). One of the slowest is accumrd() in gflow.c. There is also something slow in loopopt(), boolopt() and in builddags().
Comment #5 by yebblies — 2012-02-01T06:26:21Z
*** Issue 6771 has been marked as a duplicate of this issue. ***
Comment #6 by yebblies — 2012-02-01T06:26:32Z
*** Issue 5684 has been marked as a duplicate of this issue. ***
Comment #7 by yebblies — 2012-02-01T06:26:44Z
*** Issue 6643 has been marked as a duplicate of this issue. ***
Comment #8 by code — 2013-03-12T12:21:56Z
*** Issue 6771 has been marked as a duplicate of this issue. ***
Comment #9 by yebblies — 2014-11-29T01:47:12Z
Comment #10 by bugzilla — 2015-05-22T06:33:51Z
Comment #11 by github-bugzilla — 2015-06-19T14:55:30Z
Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/a065244aed56693b5297241b87232f11571554a3 workaround Issue 2396 - O(N^2) backend optimizations https://github.com/D-Programming-Language/druntime/commit/baface5e6b9d32cc42390774a2389d42f490fcba Merge pull request #1275 from MartinNowak/workaround2396 workaround Issue 2396 - O(N^2) backend optimizations
Comment #12 by github-bugzilla — 2015-10-04T18:18:51Z
Comment #13 by slavo5150 — 2019-05-23T10:08:18Z
Can this be closed?