On Friday, 6 December 2019 at 07:47:33 UTC, Andre Pany wrote:
>
> What is the overhead of dub, if you do not count the first run?
> (the first run compiles the script to an executable, each sub subsequent
> run from now on just calls the executable)

It's calling dmd on every run, even with your patch:

1575620540.004204 execve("/usr/bin/dmd", ["dmd", "-quiet", "-c", "-o-", "-v", "long /tmp filename.d"]
1575620540.204598 execve("long tmp filename"

... but that seems to be probePlatform, which stopWatch says
only takes 12ms.

Statting the generated file shows that it's not getting touched,
so it's definitely not getting recompiled.

> Did you compile dub using dmd or ldc? Performance of LDC with optimizations
> on is a lot better than debug builds of dmd.

dmd, but a release build with ldc doesn't decrease this overhead
at all actually.

> Kind regards
> André

It's still a huge improvement. I'll take another look at
the remaining overhead over the weekend.

On Friday, 6 December 2019 at 08:51:03 UTC, mipri wrote:
> On Friday, 6 December 2019 at 07:47:33 UTC, Andre Pany wrote:
>> [...]
>
> It's calling dmd on every run, even with your patch:
>
> 1575620540.004204 execve("/usr/bin/dmd", ["dmd", "-quiet", "-c", "-o-", "-v", "long /tmp filename.d"]
> 1575620540.204598 execve("long tmp filename"
>
> ... but that seems to be probePlatform, which stopWatch says
> only takes 12ms.
>
> Statting the generated file shows that it's not getting touched,
> so it's definitely not getting recompiled.
>
>> [...]
>
> dmd, but a release build with ldc doesn't decrease this overhead
> at all actually.
>
>> [...]
>
> It's still a huge improvement. I'll take another look at
> the remaining overhead over the weekend.

Awesome!
FYI: the platform probe could either be cached or the -Xi=compilerInfo -Xf=- info API which has been added in 2.079 for this purpose could be used.

Details: https://github.com/dlang/dub/issues/1317

On Tuesday, 3 December 2019 at 16:33:32 UTC, Petar Kirov [ZombineDev] wrote:
>
> Dub is supposed to cache every build artifact, but for some reason the `isUpToDate` function returns `false` for a single-file package I am testing with.
>
> BTW, on what OS and hardware are you testing?
> I am on Linux with an SSD, so this may explain why I get faster results than you.
>
> I'll look into the problem with Dub's `isUpToDate`.

First thing that comes to mind is that you mount your SSD with nomtime/noatime.

On Tuesday, 3 December 2019 at 18:39:12 UTC, bachmeier wrote:
> [...] rdmd works, so let's not break it without a really good reason, and I haven't seen a really good reason.

No, it doesn't. The script isn't executed, or if it is there's no effect, but the exit code doesn't indicate an error either.
Using  #!/usr/bin/dmd -run  doesn't work either (out of the box) if /tmp is mounted noexec.

On Wednesday, 4 December 2019 at 00:40:42 UTC, bachmeier wrote:
> On Tuesday, 3 December 2019 at 20:54:19 UTC, aliak wrote:
>
>> You asked for compiler source directive use cases.
>>
>> And yes, point being he can't use rdmd for writing the scripts he needs to write.
>
> I don't find it convincing to see use cases that are already done with other tools.

So you're saying that ldc and gdc are duplicated and hence wasted effort ?

In my mind having options and alternatives is as good a thing as diversity can be.

On Monday, 9 December 2019 at 12:19:31 UTC, wjoe wrote:

>> I don't find it convincing to see use cases that are already done with other tools.
>
> So you're saying that ldc and gdc are duplicated and hence wasted effort ?
>
> In my mind having options and alternatives is as good a thing as diversity can be.

ldc and gdc aren't really good examples, because those projects are separate from dmd. Their existence doesn't break dmd.

"More options" is a wonderful idea if you can make those changes *and* someone will fix the bugs and handle additional maintenance issues that arise as a result of the changes that were made. It's not a wonderful idea based on the historical record of this community. We'll end up with something that's sort of usable and gives new users yet another reason to stay away.

But as I already said, I'm not the one you have to convince. I'm just a user of the language that prefers unbroken tools.