On Tuesday, 20 March 2018 at 16:56:59 UTC, Dennis wrote:
> On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:
>> I suspect you are seeing the Windows antivirus hitting you. D runtime starts up in a tiny fraction of a second, you shouldn't be noticing it.
>
> You're totally right, disabling real-time protection makes a massive difference. I always found a second exceptionally long for a runtime to initialize, but I couldn't think of any other differences between a simple dmd-compiled program and a simple dmc-compiled program.
>
> On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:
>>  I betcha you'll see this delay (and a similar one on dmd itself, your compiles could be running at half-speed with this too)
>
> Definitely. I've tested how long tools take to simply print their help text: for the first time with virus scan, second time with virus scan and without any real-time protection. D tools seem to get the longest delay.
>
>         First   Second  No protection (miliseconds)
> dmc     84      52      16
> dmd     2400    1200    24
> dub     2300    1100    25
> ldc     4500    180     30
> gcc     240     100     18
>
>
> On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:
>> I don't know why the antivirus picks on D so much, but on my box it does and it sounds like it is on yours too. BTW that real time check box likes to keep turning itself on... so the slowness will keep coming back.
>
> Typical Windows... It keeps turning on the Windows update service too.
>
> This now leaves the question what's the best way to mitigate this, because I would gladly get rid of the second of delay any time I invoke dmd, ldc or dub as well as my own applications.

I cannot guarantee that this is the cause, but I observed that Bitdefender is very picky with Intel OMF format. I made a lot of complaints about this (it was impossible to debug a intel omf compiled exe with Bitdefender installed and the advice received from Bitdefender was to compile my executables in mscoff format. That's how my problem disappeared. Windows Defender incorporated last year Bitdefender scanning technology, maybe this is an explanation.

On Tuesday, 20 March 2018 at 16:56:59 UTC, Dennis wrote:
> On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:
> This now leaves the question what's the best way to mitigate this, because I would gladly get rid of the second of delay any time I invoke dmd, ldc or dub as well as my own applications.

In Windows Security Center Settings (where you can disable realtime scan) there is also an entry "Exclusions" (in german windows "Ausschlüsse").
I added exclusions for the folder, where I installed dmd and ldc and I added an exclusion for the folder, where I compile my D programs. Now startup of dmd and freshly compiled programs is fast again.

On Wednesday, 21 March 2018 at 13:26:48 UTC, HeiHon wrote:
> I added exclusions for the folder, where I installed dmd and ldc and I added an exclusion for the folder, where I compile my D programs. Now startup of dmd and freshly compiled programs is fast again.

I've done this too now, thanks for the tip!

On Wednesday, 21 March 2018 at 13:26:48 UTC, HeiHon wrote:
> In Windows Security Center Settings (where you can disable realtime scan) there is also an entry "Exclusions" (in german windows "Ausschlüsse").
> I added exclusions for the folder, where I installed dmd and ldc and I added an exclusion for the folder, where I compile my D programs. Now startup of dmd and freshly compiled programs is fast again.

Awesome tip!