On Monday, April 02, 2018 18:52:14 Jonathan Marler via Digitalmars-d wrote: > 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.
You both have good points. On the one hand, yes, std.path is doing more, so it's not surprising that it takes longer to compile, and in that sense, it's comparing apples and oranges. However, from the standpoint of the user, they're just calling these functions to get something done, and the implementation details don't really matter. So, from the user's standpoint, as far as compilation time goes, std.path is just worse. The reasons why are kind of irrelevant from that perspective. So, in a way, you're both right. Now, ultimately, given how D works and the functionality in std.path, I don't know that it really makes sense for it to compile as fast as Go's solution if Go's solution is doing so much less, but regardless, we should be trying to at least eliminate the unnecessary slowdowns for things like compiling unit tests, and we should be looking into how to speed up the stuff that's slow to compile (e.g. improving the compilation speed of templates in general would be a huge boon). std.path doesn't need to be as slow to compile as it is to do what it does. - Jonathan M Davis
