June 02, 2015
On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer wrote:
> But if we are talking the difference between a compiler taking 10 minutes to produce a binary that is 20% faster than a compiler that takes 1 minute, what is the threshold of pain you are willing to accept? My preference is for the 10 minute compile time to get the fastest binary. If it's possible to switch the compiler into "fast mode" that gives me a slower binary, I might use that for development.

Same here.
June 02, 2015
On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer wrote:
> My original statement was obviously exaggerated, I would not put up with days-long compile times, I'd find another way to do development. But compile time is not as important to me as it is to others.
>
> -Steve

I think if compile time was such a dealbreaker as people make it out to be, C++ would be a lot less popular.

I'm honestly in favor of making GDC the default compiler so I can have more coffee breaks ;)
June 03, 2015
On 02/06/15 21:56, weaselcat wrote:
> On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer wrote:
>> My original statement was obviously exaggerated, I would not put up
>> with days-long compile times, I'd find another way to do development.
>> But compile time is not as important to me as it is to others.
>>
>> -Steve
>
> I think if compile time was such a dealbreaker as people make it out to
> be, C++ would be a lot less popular.
You know, I keep hearing this criticism. I have no idea where it comes from.

I can tell you in no uncertain words that a project the size we're working on would compile in considerably less time had it been written in C++.

If you are only referring to small projects, then compilation time isn't a major issue one way or the other.

Shachar
June 03, 2015
Project size is irrelevant here. I had 500 line C++ project that took 10 minutes to compile (hello boost::spirit). It is impossible for C++ to compile faster than D by design. Any time it seems so you either aren't comparing same thing or get misinformed. Or do straightforward separate compilation.
June 03, 2015
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
> Project size is irrelevant here. I had 500 line C++ project that took 10 minutes to compile (hello boost::spirit). It is impossible for C++ to compile faster than D by design. Any time it seems so you either aren't comparing same thing or get misinformed. Or do straightforward separate compilation.

Even C.

Our project, back when I was doing C in the early 2000's, a "make clean all" took around one hour.
June 03, 2015
On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
> It is impossible for C++ to compile faster than D by design. Any time it seems so you either aren't comparing same thing or get misinformed. Or do straightforward separate compilation.

There are lots of features in D, that C++ does not have, that will make separate compilation and partial evaluation/incomplete types difficult. So C++ is faster than D by design, even when the compiler isn't.

The same features that many think are great about D are also the ones that makes formal reasoning about isolated parts of a D program difficult or impossible. You surely don't need a list?
June 03, 2015
On Wednesday, 3 June 2015 at 07:50:53 UTC, Paulo  Pinto wrote:
> On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
>> Project size is irrelevant here. I had 500 line C++ project that took 10 minutes to compile (hello boost::spirit). It is impossible for C++ to compile faster than D by design. Any time it seems so you either aren't comparing same thing or get misinformed. Or do straightforward separate compilation.
>
> Even C.

Now really? C was designed at a time where you couldn't even hold the source file in memory, so there is not even a need for an explicit AST.

C can essentially be "streamed" in separate passes: cpp->cc->asm->linking

If compiling C is slow, it is just the compiler or the build system, not the language.
June 03, 2015
> There are lots of features in D, that C++ does not have, that will make separate compilation and partial evaluation/incomplete types difficult. So C++ is faster than D by design, even when the compiler isn't.

I've tried to parse that last sentence a few times and I'm not sure what you mean. A theoretical compiler doesn't matter; what actual compilers do does. The empirical fact is that C++ is slower to compile than D (AFAIK C++ compiles slower than everything that isn't Scala). If you have a benchmarch that shows C++ compiling faster than D, please share it.

Atila
June 03, 2015
On Wednesday, 3 June 2015 at 09:21:55 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 3 June 2015 at 07:05:37 UTC, Dicebot wrote:
>> It is impossible for C++ to compile faster than D by design. Any time it seems so you either aren't comparing same thing or get misinformed. Or do straightforward separate compilation.
>
> There are lots of features in D, that C++ does not have, that will make separate compilation and partial evaluation/incomplete types difficult. So C++ is faster than D by design, even when the compiler isn't.

LDC seems to manage separate compilation just fine, I use it for my projects at least. in my tests I find it to be 110-150% faster than all at once.

it can get even better if you properly modularize your projects instead of having 1-2 files that build slow, which causes a lot of waiting.
June 03, 2015
On Wednesday, 3 June 2015 at 11:06:39 UTC, weaselcat wrote:
> it can get even better if you properly modularize your projects instead of having 1-2 files that build slow, which causes a lot of waiting.

Yes, sure. You can probably get the same build speeds as with C if you organize your code in a particular way or shy away from certain patterns.

What I was talking about was the language, meaning that you don't write your code to give a boost in compilation speed. Clearly possible, but if you use third party frameworks… then you're out of luck.

An analogy: SQL isn't particularly expressive, but the limitations of the language makes it possible to execute it bottom-up. NOSQL engines are even less expressive, but can be even more easily distributed.