D is supposed to compile fast.

[Mike Parker]

On Sunday, 25 November 2018 at 22:00:21 UTC, Chris Katko wrote:


>
> So 1) I have to compile manually, then link. Except that also 
> runs the files every time even if they're up-to-date. Is that 
> normal behavior for C/C++?

Yes, C and C++ compilers behave the same way.


> #1 How to I only build files that are dirty? Do I actually need 
> a build program like DUB, MAKE, or CMAKE to do that? (Can make, 
> cmake be used?) How do they recognize files are out-dated if 
> DMD can't? Is that just an industry-standard 
> specialization/separation-of-responsibilities to not have the 
> compiler auto-detect up-to-date builds?


cmake doesn't actually build anything. It generates make files or 
IDE project files. I don't know if DUB currently has an option to 
build only dirty files. Make does it by default.

To do something like that requires looking for a source file's 
corresponding object file in the output directory and only 
compiling the source if the object file doesn't exist or if it 
has an older timestamp.

But consider what happens when you change the command line 
options, say enable a version on a build that wasn't enabled 
earlier. With make, you have to run `make clean` first, otherwise 
only dirty files will get the new options. It doesn't track build 
options per file from run to run. What should the compiler do? 
Have a -clean command line switch? Maintain a database of command 
line options per file? That's the realm of build systems. The 
compiler just compiles.


>
> I've heard "just use dub" but I've also heard that dub have 
> flaws/gotchas that I can't remember when it comes to say, 
> dynamic linking DLLs/SOs. So I've been hesitant to learn it.

DUB is easy. I've been using it for years and I do full 
compilation of every file on every invocation in a 
code->build->run cycle. Some aren't happy with it because it 
doesn't support some of the things they want to use it for, but 
it has plenty of satisfied users. I'm unaware of any gotchas 
about linking shared libraries.


>
>
>
>
> #2 I ran individual file times. They're pretty shocking.
> -------------------------------------------------------
>
> I have to tell you that, as an outsider (who is VERY interested 
> in D), this is very frustrating. "Compile times are fast" != 
> "build times" is a huge misconception that borders on being a 
> clever lie or twisting of words. When people hear "compile 
> times", they think "time to compile the whole project" not 
> "time to compile a simple test case that doesn't use any 
> typical D features--also, it's not linking." Second, as shown 
> here, it's not fast even for compiling! Because the second you 
> touch std.regex (which has NO WARNINGS in the documentation), 
> you're greeted with another clever lie-by-omission: a 10x 
> explosion of build time over some modules.
>
> Now let's stop for a moment. I'm not accusing anyone, and "lie" 
> is a strong word with heavy guilt implications--like people are 
> intentionally being very sneaky to deceive new-comers. I'm not 
> saying any of that, so you can relax and put down the 
> pitchfork. I'm not attacking you or your group personally. 
> However, I can't think of any better word.
>
> So my point is, I keep running into either misconceptions that 
> conveniently make D look good, and other gotchas with NO 
> DOCUMENTATION that make the language much slower to work with 
> than expected.


There is no misleading or misconception or lying or misdirection 
here. DMD has fast compile times. Heavily templated code is going 
to slow it down, but if you compile the same sort of heavily 
templated code in C++, you'll get slow downs there as well. And 
in your case, you'll find that if you add many more files to your 
project and they aren't heavily templated, the increase in build 
time will be very small.

If someone can dig into the compilers and optimize how templates 
are handled, they might be able to shave a bit of time off, but 
when you are using a code base that does a lot of work at compile 
time, then there's no avoiding increasing the length of that 
compile time.

But that by no means is the same as saying it's not fast, because 
overall compile times in D are still fast.


>
> I mean, can you think of any module in the Python/Javascript/C# 
> standard library that simply including it will swell your 
> program to the point it can't compile? I'm not an omnipotent 
> master programmer, but as a professional, I can't recall ever 
> having this situation in another library or language.

Have you reached the point in D where you can't compile?