Building C++ modules

[H. S. Teoh]

On Thu, Aug 15, 2019 at 08:09:33PM +0000, Exil via Digitalmars-d wrote:
[...]
> See my experience with D is that it still takes over a minute to
> compile my relatively small program.

I've seen that before.  The cause is usually one or more of:

(1) Using dub.  Dub is, sorry to say, dog-slow.  I do not bother with
dub because of that (plus a variety of other reasons).  I use a saner
build system that invokes dmd directly, and it's a lot faster than using
dub.

(2) Using too many templates / CTFE.  CTFE is known to be dog-slow (Diet
templates are a leading cause of dog-slow compilation in vibe.d
projects, because they try to do too much at compile-time. I haven't
gotten around to it yet, but in my own vibe.d project the goal is to
move away from Diet templates and use a faster, home-brew HTML
generation solution instead.)  NewCTFE is supposed to improve this, but
at the rate things are going, I'm not holding my breath for it.

Templates are also known to be slow when you get into recursive
templates or just careless, wanton use of compile-time arguments where
runtime arguments do just fine.  If you reduce your use of templates,
and use runtime code where it's not important to stuff everything into
compile-time, your compile times will improve a lot.

(3) Using certain Phobos modules that are known to be very slow to
compile, such as std.regex.  The underlying cause is essentially the
same as (2), but I thought I'd point it out because sometimes it's not
obvious that that's the problem when all you did was to import Phobos.


> A minute isn't really fast.

If my D project is taking a minute to compile, I'd seriously look into
eliminating needless templates/CTFE and/or replacing dog-slow Phobos
modules with custom code.


> Even worse if you use -O with DMD (I stopped it after 20 mins).

IMNSHO, using -O with DMD is a waste of time.  It increases compilation
time, and has a higher probability of running into a compiler (usu.
backend) bug, yet the resulting executable is still woefully suboptimal
compared to, say, gdc or ldc.  Just not worth it.  If performance was
important to me (and it is, in some of my projects), I'd just use ldc2
outright and forget about DMD.


> D really isn't a fast language, or rather the only frontend is really
> really slow especially for CTFE.

I understand the sentiment, but I think it's an unfair comparison.  If I
were to implement in C++ the equivalent of the some CTFE functionality
that's making my compilation slow, I'm almost certain the resulting C++
compile times will make dmd look like lightning speed by comparison.
CTFE *is* known to be slow, no question about that, but I suspect it's
still a lot faster than what it would have taken to accomplish the same
thing in C++.


[...]
> > Compile errors that appear instantly means you're still focused and
> > can immediately get on the task of identifying the problem code.
> > Compile errors that appear after X seconds means you spend an
> > additional Y seconds refocusing your brain on the programming
> > problem at hand, and *then* get on the task of identifying the
> > problem code, thus slowing you down by (X+Y+Z) seconds rather than
> > just spending the Z seconds finding the problem.
> 
> Now you have to read and interpret something else entirely. Your not
> waiting 200 ms to continue your line of thought, your wasting minutes
> if not more if you continue to get compiler errors. Especially one of
> those template errors that are difficult to interpret. It's the same
> problem but x10 worse.

But you have to spend that time *anyway*, eventually if not right then,
when you have to fix the bug in your code.  Why make the total time even
longer by being forced to wait for long compilation times?


> Your not the person I was replying to, so sure
> maybe its something else to you, but the person I was replying to made
> it pretty clear what it was for them.
> 
> Just curious, how fast do you type? If it's about wasting time for you
> I imagine you must type pretty quickly then :P.
[...]

I type relatively fast -- not super-fast, mind you, but the point is
that long compilation times are *on top* of my typing times.  If I'm
already typing not super-fast, then I really don't want compilation
times to make the total time even longer.


T

-- 
Creativity is not an excuse for sloppiness.