D compiles fast, right? Right??

[Jonathan Marler]

On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
> Fast code fast, they said. It'll be fun, they said. Here's a D 
> file:
>
>     import std.path;
>
>
> Yep, that's all there is to it. Let's compile it on my laptop:
>
>     /tmp % time dmd -c  foo.d
>     dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total
>
>
> That... doesn't seem too fast to me. But wait, there's more:
>
>     /tmp % time dmd -c -unittest foo.d
>     dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu 
> 0.525 total
>
>
> Half. A. Second. AKA "an eternity" in dog years, err, CPU time. 
> I know this has been brought up before, and recently even, but, 
> just... just... sigh.
>
> So I wondered how fast it'd be in Go, since it's got a 
> reputation for speedy compilation:
>
>     package foo
>     import "path"
>     func Foo() string {
> 	    return path.Base("foo")
>     }
>
>     /tmp % time go tool compile foo.go
>     go tool compile foo.go  0.01s user 0.01s system 117% cpu 
> 0.012 total
>
>
> See, now that's what I'd consider fast. It has actual code in 
> the file because otherwise it complains the file isn't using 
> the imported package, because, Go things. It compiled so fast I 
> had to check I'd generated an object file, and then I learned 
> you can't use objdump on Go .o files, because... more Go things 
> (go tool objdump for the curious).
>
> Ok, so how about C++, surely that will make D look good?
>
>     #include <experimental/filesystem>  // yes, also a one-liner
>
>     /tmp % time /usr/bin/clang++ -std=c++17 -c foo.cpp
>     /usr/bin/clang++ -std=c++17 -c foo.cpp  0.45s user 0.03s 
> system 96% cpu 0.494 total
>
>     /tmp % time /usr/bin/g++ -std=c++17 -c foo.cpp
>     /usr/bin/g++ -std=c++17 -c foo.cpp  0.39s user 0.04s system 
> 99% cpu 0.429 total
>
>
> So.... yeeaaaaaaaaah. If one is compiling unit tests, which I 
> happen to pretty much only exclusively do, then trying to do 
> anything with paths in D is
>
> 1. Comparable to C++ in build times
> 2. Actually _slower_ than C++ (who'd've thunk it?) *
> 3. Gets lapped around Captain America vs The Falcon style about 
> 50 times by Go.
>
> And that's assuming there's a crazy D programmer out there 
> (hint: me) that actually tries to compile minimal units at a 
> time (with actual dependency tracking!) instead of the whole 
> project at once, otherwise it'll take even longer. And this to 
> just import `std.path`, then there's the actual work you were 
> trying to get to.
>
> Today actually made me want to write Go. I'm going to take a 
> shower now.
>
> Atila
>
> * 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.

Seems like you're comparing apples to oranges.

Go's path.go is very small, a 215 line file:
https://github.com/golang/go/blob/master/src/path/path.go
Documentation: https://golang.org/pkg/path/


Dlang's std.path is much more comprehensive with 4181 lines: 
https://github.com/dlang/phobos/blob/master/std/path.d
Documentation: https://dlang.org/phobos/std_path.html

It's over an order of magnitude more code and only takes twice as 
long to compile without unittests, and it's only fair to compare 
the "non-unittest" version of std.path with Go, since Go does not 
include unittests.

I'm not sure why you would compile the standard library unittests 
every time you compile anything. Probably a consequence of not 
having `-unittest=<pattern>`.  timotheecour suggested we add 
support for this and I agree for cases like this, where druntime 
and phobos would be exclude by default (just like we do with -i), 
meaning that your compilation example would not have compiled 
phobos unittests.