Bug 13152 – [REG2.064.2] Compiler high cpu usage and never ends
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-07-17T11:26:00Z
Last change time
2014-08-22T08:04:46Z
Keywords
performance, pull
Assigned to
nobody
Creator
mingodad
Comments
Comment #0 by mingodad — 2014-07-17T11:26:42Z
When trying to update http://www.dsource.org/projects/bcd/ to compile with 2.065 I found that the compiler seems to enter on an infinite loop with high cpu usage and never ends, memory consumption remains stable.
DMD/gdc trunk also have the same problem but gdc 4.8.1 works properly, although showing compilation errors.
To see this problem download http://svn.dsource.org/projects/bcd/trunk/bindings and on it's root folder issue this command:
make libxml2exa
The compiler never ends eating all cpu.
Comment #1 by bugzilla — 2014-07-18T07:17:53Z
I'm afraid you'll need to reduce the problem down a bit.
Comment #2 by dlang-bugzilla — 2014-07-20T08:55:43Z
Domingo, can you try removing "public" from the imports in each module? I think that's what's causing the slowdown.
I can reproduce the problem (and arrive at the same bisect result) with the following synthetic test case:
////// a.d /////
public import a;
public import b;
.....
public import y;
public import z;
////////////////
Then copy a.d to b.d, c.d, ..., z.d.
You can use the following program to generate the test files:
///////////////////// gen.d ////////////////////
import std.stdio;
enum last = 'z';
void main()
{
for (char c = 'a'; c<=last; c++)
{
auto f = File(c ~ ".d", "w");
for (char c2 = 'a'; c2<=last; c2++)
f.writefln("public import %s;", c2);
}
}
////////////////////////////////////////////////
Running `dmd a.d` will take a very long time.
Introduced in https://github.com/D-Programming-Language/dmd/pull/2448 (between 2.063 and 2.064.2).
Comment #3 by mingodad — 2014-07-20T11:32:51Z
Yes removing the "public" attribute seems to allow dmd to work as expected.
I saw that you've marked the commit that create this bug with a comment about this.
So this will be a bug ? How can we describe it better ?
Comment #4 by dlang-bugzilla — 2014-07-20T12:48:46Z
Yes, this is a compiler performance regression. I think this issue contains enough information now.