On 09/11/2018 00:12, kinke wrote:
> On Thursday, 8 November 2018 at 20:19:47 UTC, Vladimir Panteleev wrote:
>> Sounds like we're narrowing it down to the Visual Studio solution.
> 
> Mildly interested, I gave DMD master a shot with my 5-years old i5-3550
> (@4 GHz) in VS 2017 (+ a recent Visual D beta):
> 
> DMD v2.083.0-beta1 host compiler
> ---
> Win32-Debug:      12 secs
> Win32-Release: 1m 58 secs
> 
> LDC v1.13.0-beta1 host compiler
> ---
> Win32-Debug:      22 secs
> Win32-Release: 1m 28 secs
> 

Similar numbers for me too. Please note that the auto-tester shows similar values for release builds on all platforms, so I suspect very low numbers reported here are debug build timings.

> DMD's `-inline` is known to be *slow*.

Pedantically, it's not the inliner by itself, but the optimizer that cannot cope with large functions. With some improved inlining capabilities that got worse over time.

Visual Studio only provides parallel compilation of projects out of the box, you have to add it yourself for your favorite language for parallelization within a project. Igor has done that for the msbuild integration of dmd and LDC (https://github.com/dlang/visuald/pull/94), but the PR has kind of stalled due to some undesirable side effects.

Unfortunately, single file compilation is pretty slow, so there is not so much gain from switching from building per package to single file parallel compilation unless you have many cores.

On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote:
> And all builds are release builds... what good is a debug build? DMD
> is unbelievably slow in debug. If it wasn't already slow enough... if
> I try and build with a debug build, it takes closer to 5 minutes.

I just got to try a side-by-side comparison of a release and debug (as in `make -f posix.mak BUILD=debug`) build of DMD.

With a 25KLOC project, the debug build is only 36% slower.

Maybe the experience on Windows / Visual Studio is very different.

Wed, Nov 14, 2018 at 12:25 AM Vladimir Panteleev via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote:
> > And all builds are release builds... what good is a debug
> > build? DMD
> > is unbelievably slow in debug. If it wasn't already slow
> > enough... if
> > I try and build with a debug build, it takes closer to 5
> > minutes.
>
> I just got to try a side-by-side comparison of a release and debug (as in `make -f posix.mak BUILD=debug`) build of DMD.
>
> With a 25KLOC project, the debug build is only 36% slower.
>
> Maybe the experience on Windows / Visual Studio is very different.

I'm not sure how VisualStudio (read: MSBuild) should behave
differently than make?
It's not like the build script is taking a long time, it's the
invocation of DMD that takes 100% of that time.

36% slower seems highly optimistic? Perhaps you're building a debug build of DMD with a debug build of DMD? I guess that wouldn't be so slow... I suspect it's the optimiser that's very slow?

On Thursday, 15 November 2018 at 19:18:27 UTC, Manu wrote:
> I'm not sure how VisualStudio (read: MSBuild) should behave
> differently than make?
> It's not like the build script is taking a long time, it's the
> invocation of DMD that takes 100% of that time.

That seems to take about half the time for me (2 out of the 4 seconds).

> 36% slower seems highly optimistic? Perhaps you're building a debug build of DMD with a debug build of DMD? I guess that wouldn't be so slow... I suspect it's the optimiser that's very slow?

36% slower for compiling a real-life program with the built D compiler. The comparison is between a normal and debug build of DMD (used to build the program).

On Thu, Nov 15, 2018 at 8:00 PM Vladimir Panteleev via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On Thursday, 15 November 2018 at 19:18:27 UTC, Manu wrote:
> > I'm not sure how VisualStudio (read: MSBuild) should behave
> > differently than make?
> > It's not like the build script is taking a long time, it's the
> > invocation of DMD that takes 100% of that time.
>
> That seems to take about half the time for me (2 out of the 4
> seconds).
>
> > 36% slower seems highly optimistic? Perhaps you're building a debug build of DMD with a debug build of DMD? I guess that wouldn't be so slow... I suspect it's the optimiser that's very slow?
>
> 36% slower for compiling a real-life program with the built D compiler. The comparison is between a normal and debug build of DMD (used to build the program).

What was the batch size for module grouping? I wonder if batching too many modules together into a single compiler invocation makes too much data for the optimiser? Is optimisation time strictly linear with the size of the AST? Or is having more functions available for the inliner to consider increasingly expensive?

On Saturday, 17 November 2018 at 06:21:20 UTC, Manu wrote:
> What was the batch size for module grouping?

I just use dmd -i, which compiles everything at once (except Phobos/Druntime).

I just updated DMD on my windows and tried to compile hello world. It took 7.4 sec. Something is not right. Can anyone reproduce? On the same mashine running linux it compiles and runs in 0.1 sec

PS C:\Users\Welkam\Desktop\Projects> Measure-Command {dmd -run main.d}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 7
Milliseconds      : 418
Ticks             : 74184371
TotalDays         : 8.58615405092593E-05
TotalHours        : 0.00206067697222222
TotalMinutes      : 0.123640618333333
TotalSeconds      : 7.4184371
TotalMilliseconds : 7418.4371

On 18/11/2018 1:29 AM, welkam wrote:
> I just updated DMD on my windows and tried to compile hello world. It took 7.4 sec. Something is not right. Can anyone reproduce? On the same mashine running linux it compiles and runs in 0.1 sec
> 
> PS C:\Users\Welkam\Desktop\Projects> Measure-Command {dmd -run main.d}
> 
> 
> Days              : 0
> Hours             : 0
> Minutes           : 0
> Seconds           : 7
> Milliseconds      : 418
> Ticks             : 74184371
> TotalDays         : 8.58615405092593E-05
> TotalHours        : 0.00206067697222222
> TotalMinutes      : 0.123640618333333
> TotalSeconds      : 7.4184371
> TotalMilliseconds : 7418.4371

Just in case, did you disable your anti-virus first?

On Saturday, 17 November 2018 at 12:36:30 UTC, rikki cattermole wrote:
> Just in case, did you disable your anti-virus first?
Had to edit registry to turn that thing off and it still some times popup. Microsoft is so annoying.
https://imgur.com/a/x3cKjZm

On Tuesday, 6 November 2018 at 18:00:22 UTC, Vladimir Panteleev wrote:
> This is a tool + article I wrote in February, but never got around to finishing / publishing until today.
>
> https://blog.thecybershadow.net/2018/02/07/dmdprof/
>
> Hopefully someone will find it useful.

I put a start to the project then today i remembered callgrind...
What are the pros and cons in comparison with callgrind ? By coincidence i had to callgrind dmd today and got answers to a performance issue in a very straight forward way because for example:

    $ valgrind --tool=callgrind generated/debug/dmd somefile.d

is very simple procedure and produce a file that's easy to interpret in kcachegrind (which can then also produce a graph in ps format). Note that i don't try to discredit your work, i'm just curious to know.