Building C++ modules

Exil Exil at gmall.com
Fri Aug 16 14:05:54 UTC 2019


On Thursday, 15 August 2019 at 22:37:16 UTC, H. S. Teoh wrote:
> 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.
>

Already don't use Phobos and I can't eliminate needless CTFE 
cause it isn't needless. D's fast except if you use this this 
this and that. Well then it isn't fast. Especially when the whole 
point of using it are for those features. Then I'm wasting time 
trying to make my code fast for the compiler instead of using 
that time to making the code actually better.

>> 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.


  Yah I don't really use DMD anymore, too many bugs and I have to 
build it myself.


>
>> 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++.

Its a C++ project I converted, and it actually compiled faster in 
C++. I was using my own program to do what I am doing on CTFE 
now. As a result I was able to optimize it myself.

>
> [...]
>> > 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?


Point being, someone is willing to punch a wall for 100ms, I 
wonder why they aren't getting angree at other things equally. 
Especially with how horrible some error messages can be.
>
>> 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

That's my point, what are you doing to improve how fast you type? 
What WPM? One persons fast is another persons too slow, 
relatively.




More information about the Digitalmars-d mailing list