http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html

I'll be doing a followup on why D compiles fast.

Very right, and even more I might add a thing : the STL itself is just HUGE; and unless you live in a shell, you're going to use some library; that some library in all likeliness will include the STL directly or indirectly; and each and everyone of your files end up building the entire STL everytime they're built

> http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html
> 
> I'll be doing a followup on why D compiles fast.

On 19/08/10 10:35, Walter Bright wrote:
> http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html
>
> I'll be doing a followup on why D compiles fast.

While I am not a compiler writer, I do have a fairly good understanding
of compiler mechanics.

I think the length and depth of your article pretty is just about
right and accordingly I found it sufficiently concise and succinct
in explaining the issues with C++ compilation speed that one does
not need much further explanation.

May I join others in looking forward to the part 2 follow-up on why
D compiles fast.

Cheers
Justin Johansson

Walter Bright:

> http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html I'll be doing a followup on why D compiles fast.

Thank you, the article is nice and I didn't know most of the things it contains.


>the compiler is doomed to uselessly reprocess them when one file is #include'd multiple times, even if it is protected by #ifndef pairs. (Kenneth Boyd tells me that upon careful reading the Standard may allow a compiler to skip reprocessing #include's protected by #ifndef pairs. I don't know which compilers, if any, take advantage of this.)<

Probably the latest GCC versions are able to do that.
And then there is #pragma once too:
http://en.wikipedia.org/wiki/Pragma_once


>Just #include'ing the Standard results, on Ubuntu, in 74 files being read of 37,687 lines (not including any lines from multiple #include's of the same file).<

As benchmark on this Clang (the C/C++ compiler based on LLVM) uses a small program (~7500 lines of Object-C) that includes Cocoa/Cocoa.h, that is quite large:
http://clang.llvm.org/performance.html

Bye,
bearophile

Walter Bright wrote:
> http://www.drdobbs.com/blog/archives/2010/08/c_compilation_s.html
> 
> I'll be doing a followup on why D compiles fast.

On reddit:

http://www.reddit.com/r/programming/comments/d2wwp/why_c_compiles_slow/

> I'll be doing a followup on why D compiles fast.

I will say the contrary. Compiling medium size projects doesn't matter in either language. But when the size of your project starts getting very big you will have troubles in D because there is no incremental compilation. You will end up recompiling the whole thing each time which will take longer than just recompiling a single file in C++. Please be sure to mention it in your next article, otherwise it is a false advertisement. Of course it is not the language issue, but it's the issue of its only implementation.

P.S. This problem was raised many times here by Tomasz Stachowiak.

On 08/19/2010 07:48 AM, Eldar Insafutdinov wrote:
>> I'll be doing a followup on why D compiles fast.
>
> I will say the contrary. Compiling medium size projects doesn't matter in either
> language. But when the size of your project starts getting very big you will have
> troubles in D because there is no incremental compilation.

I'm a bit confused - how do you define incremental compilation? The build system can be easily set up to compile individual D files to object files, and the use the linker in a traditional manner.

> You will end up
> recompiling the whole thing each time which will take longer than just recompiling
> a single file in C++. Please be sure to mention it in your next article, otherwise
> it is a false advertisement. Of course it is not the language issue, but it's the
> issue of its only implementation.
>
> P.S. This problem was raised many times here by Tomasz Stachowiak.

I'm not sure about that. On the large C++ systems I work on, compilation is absolute agony. I don't think that that sets the bar too high.


Andrei

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article

> I'm a bit confused - how do you define incremental compilation? The build system can be easily set up to compile individual D files to object files, and the use the linker in a traditional manner.

I am not sure here, you'd better check that in posts of Tomasz Stachowiak. There was something wrong with how dmd emits template instantiations. He had to create a custom build tool that does some hackery. From my experience with D you just can't do that. I get weird errors and I end up rebuilding the whole thing.

> I'm not sure about that. On the large C++ systems I work on, compilation is absolute agony. I don't think that that sets the bar too high. Andrei

Can you please elaborate on that? From my experience and understanding if you modify one cpp file for instance, only this file will be recompiled, then the project is linked and ready to be run. If you modify a header(which happens less often) the build system quite fairly recompiles files that include it. And I use make -j of course, which makes things even easier.

Eldar Insafutdinov Wrote:

> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> 
> > I'm a bit confused - how do you define incremental compilation? The build system can be easily set up to compile individual D files to object files, and the use the linker in a traditional manner.
> 
> I am not sure here, you'd better check that in posts of Tomasz Stachowiak. There was something wrong with how dmd emits template instantiations. He had to create a custom build tool that does some hackery. From my experience with D you just can't do that. I get weird errors and I end up rebuilding the whole thing.

There used to be a number of issues with where TypeInfo was generated, references to in/out contracts and other auto-generated functions, etc, but I think they've all been addressed.

> > I'm not sure about that. On the large C++ systems I work on, compilation is absolute agony. I don't think that that sets the bar too high. Andrei
> 
> Can you please elaborate on that? From my experience and understanding if you modify one cpp file for instance, only this file will be recompiled, then the project is linked and ready to be run. If you modify a header(which happens less often) the build system quite fairly recompiles files that include it. And I use make -j of course, which makes things even easier.

It's always possible to use headers in D as well, though I think the tipping point is far different from where it is in C++.

Andrei Alexandrescu, el 19 de agosto a las 08:50 me escribiste:
> On 08/19/2010 07:48 AM, Eldar Insafutdinov wrote:
> >>I'll be doing a followup on why D compiles fast.
> >
> >I will say the contrary. Compiling medium size projects doesn't matter in either language. But when the size of your project starts getting very big you will have troubles in D because there is no incremental compilation.
> 
> I'm a bit confused - how do you define incremental compilation? The build system can be easily set up to compile individual D files to object files, and the use the linker in a traditional manner.

I think in D you can do the same level of incremental compilation as in C/C++ but is not as natural. For one, in D is not natural to separate declarations from definitions, so a file in D tends to be dependent in *many* *many* other files because of excessive imports, so even when you can do separate compilation, unless you are *extremely* careful (much more than in C/C++ I think) you'll end up having to recompile the whole project even you change just one file because of the dependency madness.

I know you can do separate compilation as in C/C++ writing the declarations in a different file, or generating/using .di files, but also you'll probably end up using libraries that don't do that (as somebody mentioned for C++ + STL) and end up in a dependency madness anyway. It's just not natural to do so in D, it even encourages not doing it as one of the main advertised features is you don't have to separate declarations from definitions.

And I'm not saying that is an easy to solve problem, I'm just saying that I agree D doesn't scale well in terms of incremental compilations for big projects, unless you go against D natural way on doing things.


-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hay manos capaces de fabricar herramientas
con las que se hacen máquinas para hacer ordenadores
que a su vez diseñan máquinas que hacen herramientas
para que las use la mano