D compiles fast, right? Right??

Jonathan Marler johnnymarler at gmail.com
Mon Apr 2 18:52:14 UTC 2018


On Monday, 2 April 2018 at 12:33:37 UTC, Atila Neves wrote:
> On Friday, 30 March 2018 at 16:41:42 UTC, Jonathan Marler wrote:
>>
>> Seems like you're comparing apples to oranges.
>
> No, I'm comparing one type of apple to another with regards to 
> weight in my shopping bag before I've even taken a bite.

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.

>> It's over an order of magnitude more code
>
> More lines of code is a liability, not an advantage.

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.


>> and it's only fair to compare the "non-unittest" version of 
>> std.path with Go, since Go does not include unittests.
>
> Absolutely not.
>
> There is *0* compile-time penalty on Go programmers when they 
> test their programs, whereas my compile times go up by a factor 
> of 3 on a one-line program. And that's >3 multiplied by 
> "already slow to begin with".

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.  In practicality, D should 
not be compiling in the standard library unittest by default.  
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.



More information about the Digitalmars-d mailing list