[Issue 2582] New: Significantly Increased Compile Times For DWT

Jan 12, 2009

d-bugmail

Feb 16, 2009

d-bugmail

Feb 22, 2009

d-bugmail

Mar 11, 2009

d-bugmail

January 12, 2009

[Issue 2582] New: Significantly Increased Compile Times For DWT

Posted by d-bugmail

Permalink

d-bugmail

Permalink

http://d.puremagic.com/issues/show_bug.cgi?id=2582

           Summary: Significantly Increased Compile Times For DWT
           Product: D
           Version: 1.039
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: business3@twistedpairgaming.com


Certain DWT programs (though not all) that compiled perfectly fine under DMD 1.037 experience suspiciously long compile times under DMD 1.039. For instance, the sample "dwt-samples\snippets\treeeditor\Snippet111.d" goes from about 30 seconds in 1.037 to over 15 minutes (I killed it after that) in 1.039.

The bug seems to exhibit some sort of compounding effect, as the more I stripped down the test case, the faster the compile time became. However, even in the smallest test case I could come up with (which unfortunately still relies on both Tango and DWT), there is still a significantly increased delay at the point where compiler stalls:

--------------------
module test;

import tango.core.Traits;
import dwt.graphics.Path;

class Foo(Dg)
{
    alias ParameterTupleOf!(Dg) DgArgs;
}

void main ()
{
    pragma(msg, __LINE__.stringof);
    new Foo!( void delegate() )( );
    pragma(msg, __LINE__.stringof);
}
--------------------

I compiled this with DSSS 0.76, DWT 3.4-1, and Tango 0.99.7 (the version that
has DMD 1.035 packaged with it:
http://downloads.dsource.org/projects/tango/snapshots/tango-bin-win32-CURRENT-dmd.1.035.zip
).

I compiled with:
rebuild -C-v test

The relevant output for DMD 1.037 was:
--------------------
{...trimmed...}
semantic3 test
13L
{no noticeable pause}
15L
semantic3 Traits
{...trimmed...}
{no linker error}
--------------------

The relevant output for DMD 1.039 was:
--------------------
{...trimmed...}
semantic3 test
13L
{pauses here for about 1 minute}
15L
semantic3 Traits
{...trimmed...}
OPTLINK (R) for Win32 Release 8.00.1
Copyright (C) Digital Mars 1989-2004 All rights reserved.
.\dwt-dwthelper-File.obj(dwt-dwthelper-File) Offset 0575BH Record Type 0091
Error 1: Previous Definition Different :
_D5tango4text4Text11__T4TextTaZ4Text4Span6__initZ
--- errorlevel 1
--------------------

The linker error seems to occur in 1.039 with every DWT sample I've tried, not just the ones that also exhibit the long compile times (but never on 1.037). So I assume that's a separate issue. I'll see if I can come up with a separate test case and bug report for that.


--

http://d.puremagic.com/issues/show_bug.cgi?id=2582 ------- Comment #1 from bugzilla@digitalmars.com 2009-02-15 20:39 ------- Error 1: Previous Definition Different : _D5tango4text4Text11__T4TextTaZ4Text4Span6__initZ Before saying this is a bug in the linker, it's worth finding why there are multiple definitions of the same thing in the source code. http://www.digitalmars.com/ctg/OptlinkErrorMessages.html#previous_definition_different --

http://d.puremagic.com/issues/show_bug.cgi?id=2582 ------- Comment #2 from moritzwarning@web.de 2009-02-21 19:47 ------- I tried to compile QTD today (http://code.google.com/p/qtd/) and encountered a problem that a file didn't finished compiling. After some testing with several dmd versions I found out that all tested versions before dmd 1.038 work, but later versions are caught in an infinite loop. It's the same problem for ldc, but gdc works (old front end version). The problem can be reproduced with "dmd -c qt/gui/QPushButton.d -ofqt/gui/QPushButton.o" and dmd version 1.038 or later (or ldc). The back trace for ldc looks like this: (gdb) bt #0 0x0000000000545ed9 in Module::imports () #1 0x0000000000546478 in Module::imports () #2 0x0000000000546478 in Module::imports () #3 0x0000000000546478 in Module::imports () #4 0x00000000005bbf1e in TemplateInstance::semantic () #5 0x0000000000573d57 in TypeInstance::resolve () #6 0x0000000000571c30 in TypeInstance::semantic () #7 0x00000000005973ea in VarDeclaration::semantic () #8 0x00000000005c8f2c in ClassDeclaration::semantic () #9 0x0000000000549bde in StorageClassDeclaration::semantic () #10 0x0000000000549dc6 in ProtDeclaration::semantic () #11 0x00000000005448c8 in Module::semantic () #12 0x00000000005be2b4 in Import::semantic () #13 0x0000000000549dc6 in ProtDeclaration::semantic () #14 0x00000000005448c8 in Module::semantic () #15 0x00000000005be2b4 in Import::semantic () #16 0x0000000000549dc6 in ProtDeclaration::semantic () #17 0x00000000005448c8 in Module::semantic () #18 0x00000000005be2b4 in Import::semantic () #19 0x0000000000549dc6 in ProtDeclaration::semantic () #20 0x00000000005448c8 in Module::semantic () #21 0x00000000005be2b4 in Import::semantic () #22 0x0000000000549dc6 in ProtDeclaration::semantic () #23 0x00000000005448c8 in Module::semantic () Looks like Module::imports from module.c is involved. It was added in dmd 1.038. Hope that helps. :) --

http://d.puremagic.com/issues/show_bug.cgi?id=2582 bugzilla@digitalmars.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Comment #3 from bugzilla@digitalmars.com 2009-03-11 14:53 ------- Fixed dmd 1.041 --

Forums