Bug 12137 – [REG DMD2.065-b3] Huge decline in performance

When compiling vibe.d, the performance and memory requirements of DMD got significantly worse (about 7x slower and up to 1.5x more memory requirement). Some measurements in Windows/32: DMD 2.064: 5.5 s with about 780 MiB memory used DMD 2.065-b1: 36 s with about 880 MiB memory used DMD 2.065-b3: 40 s with about 880 MiB memory used Others report even higher numbers for memory usage [1] [2]. This gets critical, as DMD-32 now fails to compile a number of existing projects due to out-of-memory errors. Simplest way to reproduce is with the latest DUB release candidate [3]: $ dub fetch vibe-d --version=0.7.19-beta.3 $ dub build vibe-d --force -v [1]: http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/11179/ [2]: http://forum.dlang.org/thread/[email protected]?page=4#post-uckojuzmhytcyjtotomt:40forum.dlang.org [3]: http://code.dlang.org/download

(In reply to comment #0) > When compiling vibe.d, the performance and memory requirements of DMD got > significantly worse (about 7x slower and up to 1.5x more memory requirement). > Some measurements in Windows/32: > > DMD 2.064: 5.5 s with about 780 MiB memory used > DMD 2.065-b1: 36 s with about 880 MiB memory used > DMD 2.065-b3: 40 s with about 880 MiB memory used I'm really not sure what is the problem. In my windows PC, checkout v2.064 tag on dmd/druntime/phobos repositories, then the built environment will cause same issue. But the released 2.064 environment (extracted from zip file) does not cause the issue...

Interesting. Could it be that the last release was built using VisualStudio instead of DMC? Even if that seems to be almost to much of a difference for that to explain it...

Any chance the failing dmds are being built with the old snn.lib?

(In reply to comment #2) > Interesting. Could it be that the last release was built using VisualStudio > instead of DMC? Even if that seems to be almost to much of a difference for > that to explain it... I'm using dmc for building dmd. So it would be unrelated. (In reply to comment #3) > Any chance the failing dmds are being built with the old snn.lib? Unfortunately no. The built dmd.exe from the 2.064 released binaries (dmd2/windows/bin and dmd/windows/lib) causes same issue. Note that, I'm using the latest dmc release: http://ftp.digitalmars.com/Digital_Mars_C++/Patch/dm857c.zip

(In reply to comment #4) > (In reply to comment #3) > > Any chance the failing dmds are being built with the old snn.lib? > > Unfortunately no. The built dmd.exe from the 2.064 released binaries > (dmd2/windows/bin and dmd/windows/lib) causes same issue. > > Note that, I'm using the latest dmc release: > http://ftp.digitalmars.com/Digital_Mars_C++/Patch/dm857c.zip But really, what else could it be? If you're compiling the same 2.064 code and getting a slower compiler out, what else could do that? I assume you were using 2.064 druntime/phobos to test the 2.064 compiler.

(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Any chance the failing dmds are being built with the old snn.lib? > > > > Unfortunately no. The built dmd.exe from the 2.064 released binaries > > (dmd2/windows/bin and dmd/windows/lib) causes same issue. > > > > Note that, I'm using the latest dmc release: > > http://ftp.digitalmars.com/Digital_Mars_C++/Patch/dm857c.zip > > But really, what else could it be? If you're compiling the same 2.064 code and > getting a slower compiler out, what else could do that? snn.lib is in dmd/windows/lib, and even if I replace the directory with the one in the released 2.064, slow compiler will be built. So I really not sure what is wrong... > I assume you were > using 2.064 druntime/phobos to test the 2.064 compiler. Yes. I checkout v2.064 tag in dmd/druntime/phobos repositories, then build them with the built (== slow) 2.064 dmd.exe.

(In reply to comment #6) > > snn.lib is in dmd/windows/lib, and even if I replace the directory with the one > in the released 2.064, slow compiler will be built. So I really not sure what > is wrong... > Is it possible the snn.lib from the 2.064 zip is also the old snn.lib? I have CD81574FAA1B6876E053A5C3A16C8DFBF6D69100 in my dmc dir and D65F7172F521940828C08EB9F5D09214490DBFAB in my dmd2\windows\bin dir. I'm sure one of these is the wrong one, but they both came from recent zips (about a month ago)

(In reply to comment #7) > Is it possible the snn.lib from the 2.064 zip is also the old snn.lib? > The snn.lib in 2.064.2 is 555KB and the one in the 2.065.0-b3 zip is 561KB. From what I recall, the smaller one is the one with the malloc fixes.

The correct snn.lib is: 08/03/2013 12:20 AM 567,808 snn.lib

(In reply to comment #9) > The correct snn.lib is: > > 08/03/2013 12:20 AM 567,808 snn.lib OK, understand. I copied snn.lib from dmd2.064.zip to c:/dm/lib (dmc library directory), then re-compile dmd.exe. Then the generated dmd does not cause the issue.

From where do I get the correct snn.lib?

(In reply to comment #11) > From where do I get the correct snn.lib? Currently it is in 2.064.zip. http://downloads.dlang.org/releases/2013/dmd.2.064.zip

Fixed with https://github.com/D-Programming-Language/installer/pull/66.

It would be nice to be able to test this. Is there a way to get the version of snn.lib? If not, could one be added? Then we could at least have a unittest rather than a silent performance regression.