On 4/2/18 4:05 PM, Jonathan M Davis wrote:

> One concern I have is version(unittest) blocks. In order to avoid code
> breakage, those would need to still be compiled in. I know that I've
> personally used version(unittest) blocks that had package access level and
> were then imported in the unit tests within that package in order to avoid
> declaring helper types or functions in each module. So, treating
> version(unittest) blocks like they're not there when importing a module
> would definitely break som existing code. It could be argued that such uses
> should be deprecated in some manner, but simply not compiling in anything
> related to -unittest in imported modules would be a problem. However, aside
> from maybe __traits(getUnitTests), I don't see why it would be a problem to
> ignore code inside a unittest block except for when that module is being
> compiled (or when that unittest block is inside a template that's being
> compiled).

version(unittest) blocks would have to be rethought in your code at some point. I think they have to go through the same rules -- only if __traits(getUnitTests) is used would it be included.

I have run into horrible problems with version(unittest), where I actually defined a virtual function (by accident, of course) for unittests only, and then when you compile/link with different modes of -unittest you have spectacular failure. There have been similar problems in phobos: https://github.com/dlang/phobos/pull/5932

There are other ways to achieve the same things, and while not as convenient, they would be safer and less troublesome for imports.

-Steve

On Monday, 2 April 2018 at 19:32:33 UTC, Steven Schveighoffer wrote:
> On 4/2/18 12:28 PM, Andrei Alexandrescu wrote:
>> On 04/02/2018 12:22 PM, H. S. Teoh wrote:
>>> Lately this has been mentioned more and more frequently.  So what's the
>>> status on this?  Are we going to move forward with making it so that
>>> -unittest only applies to modules supplied on the command-line?
>>>
>>> Has there been an investigation into how __traits(getUnitTests) could be
>>> made to work in spite of this change?
>> 
>> Walter and I are willing to go with the change assuming no showstopper presents itself, but we don't have time budgeted for it. So it needs a strong champion.
>
> If nobody else volunteers, I might give it a shot at the hackathon. I'd need help figuring out where the important bits are, so I may be bugging compiler devs that day :)
>
> -Steve

Wow. I think we better get an extra hackathon day then :)
(there's a lot more work just "like this" lying around)

On Monday, April 02, 2018 17:15:40 Steven Schveighoffer via Digitalmars-d wrote:
> On 4/2/18 4:05 PM, Jonathan M Davis wrote:
> > One concern I have is version(unittest) blocks. In order to avoid code breakage, those would need to still be compiled in. I know that I've personally used version(unittest) blocks that had package access level and were then imported in the unit tests within that package in order to avoid declaring helper types or functions in each module. So, treating version(unittest) blocks like they're not there when importing a module would definitely break som existing code. It could be argued that such uses should be deprecated in some manner, but simply not compiling in anything related to -unittest in imported modules would be a problem. However, aside from maybe __traits(getUnitTests), I don't see why it would be a problem to ignore code inside a unittest block except for when that module is being compiled (or when that unittest block is inside a template that's being compiled).
>
> version(unittest) blocks would have to be rethought in your code at some
> point. I think they have to go through the same rules -- only if
> __traits(getUnitTests) is used would it be included.
>
> I have run into horrible problems with version(unittest), where I actually defined a virtual function (by accident, of course) for unittests only, and then when you compile/link with different modes of -unittest you have spectacular failure. There have been similar problems in phobos: https://github.com/dlang/phobos/pull/5932
>
> There are other ways to achieve the same things, and while not as convenient, they would be safer and less troublesome for imports.

I do think that there's some value in being able to do version(unittest) to code and import it, but I can certainly live with losing that ability if it's really needed to fix the situation with unit tests being compiled in when they shouldn't. Regardless, my main point was that there is existing code which relies on the current behavior. So, if we want to change that behavior without just pulling the rug out from under existing code, we're going to need some sort of deprecation process for it, whereas I would think that it would be possible to stop compiling unittest blocks when importing modules without breaking any code.

- Jonathan M Davis

On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:

> My point was that GO's path library is very different from dlang's std.path library.  It has an order of magnitude less code so the point was that you're comparing a very small library with much less functionality to a very large one.

I understood your point. I'm not sure you understood mine, which is: I don't care. I want to get work done, and I don't want to wait for the computer.

> I didn't say anything about whether it was advantageous, the point was that it's more code so you should take that into account when you evaluate performance.  You're post was misleading because it was assuming that both libraries were comparable when in reality they appear to be very different.

I disagree. They're very similar in the sense that, if I want to build a path and want to rely on the standard library, it takes vastly different amounts of time to compile my code in one situation vs the other.


> My point was that if you want to compare "compile-time" performance, you should not include the unittests in D's time since Go does not include unittests.

"Go does not include unittests"? Under some interpretations I guess that could be viewed as correct, but in practical terms I can write Go tests without an external library (https://golang.org/pkg/testing/)/ Whether it's a language keyword or not is irrelevant.

What _is_ relevant (to me) is that I can write Go code that manipulates paths and test it with everything building in less time that it takes to render a frame in a videogame, whereas in D...

> In practicality, D should not be compiling in the standard library unittest by default.

I think everyone is in agreement here.

> This is a problem that should be fixed but still doesn't change the fact that not taking this into consideration would be an unfair comparison.

No, no, no, a thousand times more no.

We can't make a marketing point of D compiling so fast it might as well be a scripting language when it's not even true. I get a better edit-compile-test cycle in *C++*, which is embarassing.

Atila

On Sunday, 1 April 2018 at 02:40:26 UTC, Walter Bright wrote:
> On 3/30/2018 1:17 PM, Andrei Alexandrescu wrote:
>> Could be faster.
>
> It's been a fair amount of time since somebody has done profiling of dmd. It needs to be done. There's probably plenty of low hanging fruit. Speculating about why it is slow is pointless without data.

Well Surprisingly enough the biggest function in a profile for sane code, (no templates) is called spellerY.

On Tue, Apr 03, 2018 at 10:24:15AM +0000, Atila Neves via Digitalmars-d wrote: [...]
> We can't make a marketing point of D compiling so fast it might as well be a scripting language when it's not even true. I get a better edit-compile-test cycle in *C++*, which is embarassing.
[...]

+1.  And this is why our "fast code fast" slogan makes me cringe.  We need to do some serious work on delivering that "fast" promise.


T

-- 
Caffeine underflow. Brain dumped.

On Tuesday, 3 April 2018 at 10:24:15 UTC, Atila Neves wrote:
> On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:
>
>> My point was that GO's path library is very different from dlang's std.path library.  It has an order of magnitude less code so the point was that you're comparing a very small library with much less functionality to a very large one.
>
> I understood your point. I'm not sure you understood mine, which is: I don't care. I want to get work done, and I don't want to wait for the computer.

You still missed my point.  You're post was saying that "D does not compile as fast as GO". But the libraries you're comparing are vastly different.  If you're post was saying, "dlang's std.path compiles much slower than GO's" then you would be fine.  However, you're post was misleading saying the Go compile's faster than D in general, and I was pointing out that the use case you provided doesn't apply in the general case, it only applies to a library with the same name/type of functionality.


>
>> I didn't say anything about whether it was advantageous, the point was that it's more code so you should take that into account when you evaluate performance.  You're post was misleading because it was assuming that both libraries were comparable when in reality they appear to be very different.
>
> I disagree. They're very similar in the sense that, if I want to build a path and want to rely on the standard library, it takes vastly different amounts of time to compile my code in one situation vs the other.
>

I refer to my previous answer.  Your example shows that dlang's std.path compiles slower than GO's, but that doesn't say anything about the compile performance for both languages in the general case.  To make such a claim you should compare the exact same "functionality" implemented in both languages.


>
>> My point was that if you want to compare "compile-time" performance, you should not include the unittests in D's time since Go does not include unittests.
>
> "Go does not include unittests"? Under some interpretations I guess that could be viewed as correct, but in practical terms I can write Go tests without an external library (https://golang.org/pkg/testing/)/ Whether it's a language keyword or not is irrelevant.
>
> What _is_ relevant (to me) is that I can write Go code that manipulates paths and test it with everything building in less time that it takes to render a frame in a videogame, whereas in D...

You're totally misunderstanding me.  I was just saying that if you want to compare the compile speed of D vs GO (IN THE GENERAL CASE), you should not include the unittests in D's performance because you weren't including them in your GO example.

>> This is a problem that should be fixed but still doesn't change the fact that not taking this into consideration would be an unfair comparison.
>
> No, no, no, a thousand times more no.
>
> We can't make a marketing point of D compiling so fast it might as well be a scripting language when it's not even true. I get a better edit-compile-test cycle in *C++*, which is embarassing.
>
> Atila

You totally misunderstood what I was saying once again.  I agree with what you said here, but it has nothing to do with what I was saying.

If your point is that it takes too long to access std.path's functionality then I completely agree. What I am arguing against is that your example is not evidence that GO compiles faster than D in general. You're example is comparing 2 different libraries in 2 different languages, not about the languages themselves.

On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
> * Building a whole project in C++ still takes a lot longer since D scales much better, but that's not my typical worflow, nor should it be anyone else's.

I can write code for days without even saving :)
What's the point to compile code that's not supposed to work?

On Tuesday, 3 April 2018 at 19:07:54 UTC, Jonathan Marler wrote:
> On Tuesday, 3 April 2018 at 10:24:15 UTC, Atila Neves wrote:
>> On Monday, 2 April 2018 at 18:52:14 UTC, Jonathan Marler wrote:
>>> My point was that if you want to compare "compile-time" performance, you should not include the unittests in D's time since Go does not include unittests.
>>
>> "Go does not include unittests"? Under some interpretations I guess that could be viewed as correct, but in practical terms I can write Go tests without an external library (https://golang.org/pkg/testing/)/ Whether it's a language keyword or not is irrelevant.
>>
>> What _is_ relevant (to me) is that I can write Go code that manipulates paths and test it with everything building in less time that it takes to render a frame in a videogame, whereas in D...
>
> You're totally misunderstanding me.  I was just saying that if you want to compare the compile speed of D vs GO (IN THE GENERAL CASE), you should not include the unittests in D's performance because you weren't including them in your GO example.

I feel that's probably the case for any comparisons across two languages, you are going to have a person that is more knowledgeable in one language than another. Mistakes are going to be made, but I think it should be blatantly obvious that one language is going to compiler slower if it is compiling all the unittests for a library compared to one that isn't. That's just blatant bias against D, not a mistake from misunderstanding Go.

On Tuesday, 3 April 2018 at 21:17:35 UTC, Rubn wrote:
> I feel that's probably the case for any comparisons across two languages, you are going to have a person that is more knowledgeable in one language than another. Mistakes are going to be made, but I think it should be blatantly obvious that one language is going to compiler slower if it is compiling all the unittests for a library compared to one that isn't. That's just blatant bias against D, not a mistake from misunderstanding Go.

Yeah, I don't understand that either. Unit tests can be arbitrarily large, so no matter how fast the compiler, it would always be possible to make it take longer than any other language.