Jump to page: 1 2
Thread overview
[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed
Apr 10, 2015
Daniel Kozak
Apr 10, 2015
Daniel Kozak
Apr 10, 2015
Wyatt
Apr 13, 2015
Martin Krejcirik
Apr 20, 2015
Martin Nowak
Apr 20, 2015
Martin Nowak
Apr 20, 2015
Martin Nowak
Apr 20, 2015
Iain Buclaw
Apr 20, 2015
Martin Nowak
May 08, 2015
Martin Nowak
May 22, 2015
weaselcat
Jun 27, 2015
Walter Bright
Jun 28, 2015
Kenji Hara
Jul 12, 2015
Walter Bright
April 10, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

Daniel Kozak <kozzi11@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kozzi11@gmail.com

--- Comment #1 from Daniel Kozak <kozzi11@gmail.com> ---
My timings:
                2.066.1|  2.067
-----------------------------------------
debug -c       4.300  |  4.500
debug -c -o-       3.500  |  3.500
release -c       4.000  |  4.100
release -c -o-       3.260  |  3.310
release -c -O       6.400  |  6.700
release -c -o- -O  3.280  |  3.320
release               5.750  |  5.600
release -O       8.200  |  8.100


So for me difference in compile speed is almost same

--
April 10, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #2 from Daniel Kozak <kozzi11@gmail.com> ---
s/same/none

--
April 10, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

Wyatt <wyatt.epp@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wyatt.epp@gmail.com

--- Comment #3 from Wyatt <wyatt.epp@gmail.com> ---
(In reply to Daniel Kozak from comment #1)
> 
> So for me difference in compile speed is almost same

I wonder if this isn't at least partially platform-dependent?

--
April 13, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

Martin Krejcirik <mk@krej.cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mk@krej.cz

--- Comment #4 from Martin Krejcirik <mk@krej.cz> ---
I'm not sure how relevant this is to the general compilation speed, but anyway:

import  std.regex;

auto RE_VARSET = regex(r"(?<!!\w+.*)!(\w+)\s*=\s*([\w!.-]+|`.+`|" ~ `".*")[
\t]*`,"i");
auto RE_CMD    = regex(r"!([A-Z_]+)\(([A-Za-z0-9_ .:;!,@{}/*-]*)\)");


dmd 2.065
real    0m3.789s
user    0m3.548s
sys     0m0.232s

dmd 2.066.1
real    0m4.628s
user    0m4.328s
sys     0m0.292s

dmd 2.067
real    0m5.260s
user    0m4.940s
sys     0m0.308s

--
April 20, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #5 from Martin Nowak <code@dawg.eu> ---
(In reply to Martin Krejcirik from comment #4)
> I'm not sure how relevant this is to the general compilation speed, but anyway:
> 
> import  std.regex;
> 
> auto RE_VARSET = regex(r"(?<!!\w+.*)!(\w+)\s*=\s*([\w!.-]+|`.+`|" ~ `".*")[
> \t]*`,"i");
> auto RE_CMD    = regex(r"!([A-Z_]+)\(([A-Za-z0-9_ .:;!,@{}/*-]*)\)");

This spends most of it's time in CTFE interpretation.
I get a 5-10% speedup when compiling v2.067.0 on my machine vs. using the
released binary, most likely because of a newer gcc 4.9.2 vs. gcc 4.7.2 on the
debian build image.

--
April 20, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #6 from Martin Nowak <code@dawg.eu> ---
That orange library is a really terrible example. Why would someone use single
file compilation for object and header only to pack everything into a static
library.
If I do build everything at once (including headergen -Hfimport -op) this takes
400ms instead of 8.5s.
There is still a slowdown from 400ms to 450ms comparing 2.066.1 and 2.067.0.
Seems to be mostly cause by more allocations in the compiler.

--
April 20, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #7 from Martin Nowak <code@dawg.eu> ---
This slowdown comes from
https://github.com/D-Programming-Language/dmd/pull/4384, which does instantiate
additional templates in order to resolve link bugs.
The problem is amplified by using single file compilation.

--
April 20, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #8 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Martin Nowak from comment #5)
> (In reply to Martin Krejcirik from comment #4)
> > I'm not sure how relevant this is to the general compilation speed, but anyway:
> > 
> > import  std.regex;
> > 
> > auto RE_VARSET = regex(r"(?<!!\w+.*)!(\w+)\s*=\s*([\w!.-]+|`.+`|" ~ `".*")[
> > \t]*`,"i");
> > auto RE_CMD    = regex(r"!([A-Z_]+)\(([A-Za-z0-9_ .:;!,@{}/*-]*)\)");
> 
> This spends most of it's time in CTFE interpretation.
> I get a 5-10% speedup when compiling v2.067.0 on my machine vs. using the
> released binary, most likely because of a newer gcc 4.9.2 vs. gcc 4.7.2 on
> the debian build image.

Maybe the speculative devirtualization in gcc-4.9 is in some part responsible for that.  Just thinking out loud...

--
April 20, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #9 from Martin Nowak <code@dawg.eu> ---
(In reply to Iain Buclaw from comment #8)
> Maybe the speculative devirtualization in gcc-4.9 is in some part responsible for that.  Just thinking out loud...

We should probably update the compilers across the bank to build releases. Especially replacing DMC with VS would result in a huge speedup.

--
May 08, 2015
https://issues.dlang.org/show_bug.cgi?id=14431

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com

--- Comment #10 from Martin Nowak <code@dawg.eu> ---
*** Issue 14540 has been marked as a duplicate of this issue. ***

--
« First   ‹ Prev
1 2