One of the primary limitations of code development and
productivity is software build time.  Building a complex piece
of software such as Microsoft Windows can take hours or all night.
C++ compiling is rather slow.  If something takes several hours to
build it is less usable and limits the ability to test complex builds.

The D language and its compiled libraries could be benchmarked with C++
on very large code builds.  If something takes several hours on C++ with all the
library dependancies then it should be much faster with D.

In a recent acm article "Game Development: Harder Than You Think" about game design and complexity the author lists software build time as a limitation. Complex games written is Visual C++ can take half an hour or more to compile and build.

The author stated of the article stated, "In general, C++ seems to encourage long build times. Once the build time has grown too long, a team may end up putting a significant amount of work into refactoring their source code to make it build more quickly."

Here is the link. http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=114&page=3

Build time and link time should be an important part of software design.  They even list making build executable on parelell hardware.

In article <c1rpjo$46v$1@digitaldaemon.com>, Pride of Higara says...
>
>One of the primary limitations of code development and productivity is software build time.

gtkmm - the C++ binding to GTK - takes something like
30 minutes to build
DUI - the D binding to GTK - takes 3 seconds to build
plus the linking time.

granted gtkmm has about 90k lines and DUI only 52954 lines.

Ant

I'm skeptical that most programmers care about build times - if they did, they'd switch to DMC++ which is way faster. I remember one coder telling me that build times were the overriding consideration in selecting a compiler, yet he was using far and away the slowest compiler on the market.

Check out this comparison of wxWindows build speeds: http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html

Walter wrote:

>I'm skeptical that most programmers care about build times - if they did,
>they'd switch to DMC++ which is way faster. I remember one coder telling me
>that build times were the overriding consideration in selecting a compiler,
>yet he was using far and away the slowest compiler on the market.
>
>Check out this comparison of wxWindows build speeds:
>http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html
>  
>
Coming from the man who developed a quicker compiler, was it a good investment to make the compiler quicker?

-- 
-Anderson: http://badmama.com.au/~anderson/

Total build time not only depends on the compiler, but also on the build environment used. The common GCC/make combination on most flavours of unix for example can be slow because a new GCC process is started for each .c file (and new shells for each submake, etc).

I personally use Ant to build CPP sources, and use the GCC feature that allows you to send the source file names of _all_ files you need to compile all at once on the command line. This gives some significant time savings (in my case at least). Don't know how Visual Studio handles this though

"Walter" <walter@digitalmars.com> wrote in message news:c1rvf0$g9v$1@digitaldaemon.com...
> I'm skeptical that most programmers care about build times - if they did, they'd switch to DMC++ which is way faster. I remember one coder telling
me
> that build times were the overriding consideration in selecting a
compiler,
> yet he was using far and away the slowest compiler on the market.
>
> Check out this comparison of wxWindows build speeds: http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html
>
>

In article <c1s8fg$11mt$1@digitaldaemon.com>, Jeroen van Bemmel says...
>
>Total build time not only depends on the compiler, but also on the build environment used. The common GCC/make combination on most flavours of unix for example can be slow because a new GCC process is started for each .c file (and new shells for each submake, etc).

shhh. don't tell anyone, dmd looks much better if noone notice that.

>
>I personally use Ant to build CPP sources, and use the GCC feature that allows you to send the source file names of _all_ files you need to compile all at once on the command line. This gives some significant time savings (in my case at least). Don't know how Visual Studio handles this though

how significante is that?

on my example (gtkmm / DUI) it's on the order of the hundreads.

Ant

Walter wrote:

> I'm skeptical that most programmers care about build times - if they did,
> they'd switch to DMC++ which is way faster. I remember one coder telling me
> that build times were the overriding consideration in selecting a compiler,
> yet he was using far and away the slowest compiler on the market.

In companies the reasons are often political and to some degree economic.  The place I currently work is a pretty big MS supporter and the build team would tell me to climb a tree if I asked to use a C++ compiler other than Visual Studio.  They would have to purchase it, learn it, write build scripts for it, and support it separately from the standard farm of VS boxes.  But then they also told me to climb a tree when I tried to convince them to let me use Boost, because it offered them no place to pass the buck :)  Guess what I'm saying is that compiler features alone don't always have a lot to do with why one is chosen over the other.  And while build speed can be quite important for large projects but there are other issues too... standards conformance, clarity of error reporting, library support (why Visual Studio beat out Borland), etc.


Sean

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c1s6k9$s5n$1@digitaldaemon.com...
> Walter wrote:
>
> >I'm skeptical that most programmers care about build times - if they did, they'd switch to DMC++ which is way faster. I remember one coder telling
me
> >that build times were the overriding consideration in selecting a
compiler,
> >yet he was using far and away the slowest compiler on the market.
> >
> >Check out this comparison of wxWindows build speeds: http://biolpc22.york.ac.uk/wx/wxhatch/wxMSW_Compiler_choice.html
> >
> >
> Coming from the man who developed a quicker compiler, was it a good investment to make the compiler quicker?

*I* care about fast build times <g>. It makes me a lot more productive.

"Sean Kelly" <sean@ffwd.cx> wrote in message news:c1tag4$2qsq$1@digitaldaemon.com...
> Walter wrote:
>
> > I'm skeptical that most programmers care about build times - if they
did,
> > they'd switch to DMC++ which is way faster. I remember one coder telling
me
> > that build times were the overriding consideration in selecting a
compiler,
> > yet he was using far and away the slowest compiler on the market.
>
> In companies the reasons are often political and to some degree economic.  The place I currently work is a pretty big MS supporter and the build team would tell me to climb a tree if I asked to use a C++ compiler other than Visual Studio.  They would have to purchase it, learn it, write build scripts for it, and support it separately from the standard farm of VS boxes.  But then they also told me to climb a tree when I tried to convince them to let me use Boost, because it offered them no place to pass the buck :)  Guess what I'm saying is that compiler features alone don't always have a lot to do with why one is chosen over the other.  And while build speed can be quite important for large projects but there are other issues too... standards conformance, clarity of error reporting, library support (why Visual Studio beat out Borland), etc.

I agree that other considerations are also important. There are people for whom the brand name on the box is the only consideration. I just need to do a better job with branding <g>.

> how significante is that?

I did a quick test: parallel='true' builds in 46 seconds, parallel='false' in 48-49. So that's about 5% pure for passing all files on the commandline (true), not too shocking but still usable. The difference with a make-based build environment is more significant though; unfortunately, I threw away the make scripts long ago...