[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-04-13 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

Martin Krejcirik  changed:

   What|Removed |Added

 CC||m...@krej.cz

--- Comment #4 from Martin Krejcirik  ---
I'm not sure how relevant this is to the general compilation speed, but anyway:

import  std.regex;

auto RE_VARSET = regex(r"(?

[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-04-19 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #5 from Martin Nowak  ---
(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"(? \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.

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-04-19 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #6 from Martin Nowak  ---
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.

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-04-19 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #7 from Martin Nowak  ---
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.

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-04-20 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #8 from Iain Buclaw  ---
(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"(? > \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...

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-04-20 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #9 from Martin Nowak  ---
(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.

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-05-07 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

Martin Nowak  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #10 from Martin Nowak  ---
*** Issue 14540 has been marked as a duplicate of this issue. ***

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-05-22 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

weaselcat  changed:

   What|Removed |Added

 CC||r9shacklef...@gmail.com

--- Comment #11 from weaselcat  ---
Hi,

maybe it's best to promote CyberShadow's "Are we slim yet?" histogram tool? It
was able to easily pinpoint exactly which commit caused this.

http://digger.k3.1azy.net/trend/

maybe some sort of automated regression alert.
Bye.

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-06-27 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #12 from Walter Bright  ---
(In reply to Martin Nowak from comment #7)
> 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.

The trouble is the compiler would not instantiate a template if that template
was already instantiated by an imported model, on the assumption that the
instantiation would exist in the object code generated when the imported module
was separately compiled.

The problem was that if A imports B, and B imports A, A and B are compiled
separately, and so the template was never instantiated (see
https://issues.dlang.org/show_bug.cgi?id=2644). The 4384 fixed this by always
instantiating templates if the imported module also imported root modules, as
computed by TemplateInstance::needsCodegen().

The trouble with that, and the slowdown, is the commonplace practice of having
every module in a project import every other module.

An obvious workaround for users is to compile modules that mutually import each
other on the same command to dmd.

A possible solution to this was proposed by Martin Nowak:

"I think we should define a rule for which module is responsible for the
instantiation when they mutually import each other. I'd suggest that the module
with the lexicographically smaller module name does it."

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-06-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

Kenji Hara  changed:

   What|Removed |Added

   Keywords||performance, pull

--- Comment #13 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/4784

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-07-11 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14508

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-08-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-08-30 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #14 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/6c14fadca403a61a578795ec0fb71f9340c7b543
fix Issue 14431 - huge slowdown of compilation speed

In the pull request #4384, all instance has been changed to invoke
semantic3(). It was for the link-failure issue in specific case, but it
was too excessive.

1. Semantic analysis strategy for template instances:
  We cannot determine which instance does not need to be placed in object
file until semantic analysis completed. Therefore, for all templates
instantiated in root module, compiler should invoke their semantic3 --
regardless of whether those are also instantiated in non-root module. If
a template is _only_ instantiated in non-root module, we can elide its
semantic3 (and for the compilation speed we should do that).

2. Code generation strategy for template instances:
  If a template is instantiated in non-root module, compiler usually does
not have to put it in object file. But if a template is instantiated in
both of root and non-root modules which mutually import each other, it
needs to placed in objfile.

https://github.com/D-Programming-Language/dmd/commit/92fcc9da72e2889406031a34d9a5d22b075f7d50
Merge pull request #4944 from 9rnsr/fix14431

[REG 2.067.0] Issue 14431 - huge slowdown of compilation speed

--


[Issue 14431] [REG 2.067.0] huge slowdown of compilation speed

2015-09-01 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14431

--- Comment #15 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/6c14fadca403a61a578795ec0fb71f9340c7b543
fix Issue 14431 - huge slowdown of compilation speed

https://github.com/D-Programming-Language/dmd/commit/92fcc9da72e2889406031a34d9a5d22b075f7d50
Merge pull request #4944 from 9rnsr/fix14431

--