On Saturday, 14 October 2017 at 09:03:05 UTC, Joakim wrote:
On Saturday, 14 October 2017 at 04:36:25 UTC, Saurabh Das wrote:
[...]
I can reproduce on linux/x64, looks like a memory leak, as dmd
balloons out to eat up all available memory until it's killed.
I see it with this minimal command
On Saturday, 14 October 2017 at 04:36:25 UTC, Saurabh Das wrote:
On Wednesday, 11 October 2017 at 08:11:37 UTC, Jonathan M Davis
wrote:
On Wednesday, October 11, 2017 06:25:19 Dhananjay via
Digitalmars-d-learn wrote:
Hello,
I am upgrading to DMD 2.076.1 from DMD 2.069.2 (similar
results on 2.
On Wednesday, 11 October 2017 at 08:11:37 UTC, Jonathan M Davis
wrote:
On Wednesday, October 11, 2017 06:25:19 Dhananjay via
Digitalmars-d-learn wrote:
Hello,
I am upgrading to DMD 2.076.1 from DMD 2.069.2 (similar
results on 2.075.1), and seeing a huge increase in unittest
compilation time w
On Wednesday, October 11, 2017 06:25:19 Dhananjay via Digitalmars-d-learn
wrote:
> Hello,
>
> I am upgrading to DMD 2.076.1 from DMD 2.069.2 (similar results
> on 2.075.1), and seeing a huge increase in unittest compilation
> time when the -deps parameter is also passed to dmd. This is on
> both O
Another observation:
wc -l test.dep (for "-deps=test.dep ... -unittest -main" command):
Linux 2.076.1: 41389
Linux 2.069.1: 144
Making small changes to 2.069.1 runtimes (I had run with a
different program by mistake. The measurement is still of the
same order)
On Wednesday, 11 October 2017 at
Hello,
I am upgrading to DMD 2.076.1 from DMD 2.069.2 (similar results
on 2.075.1), and seeing a huge increase in unittest compilation
time when the -deps parameter is also passed to dmd. This is on
both OSX and linux. What can be the cause of this?
Sample program:
import std.stdio: wri
