Why C++ compiles slowly

[Steven Schveighoffer]

On Wed, 25 Aug 2010 15:11:17 -0400, retard <re at tard.com.invalid> wrote:

> Wed, 25 Aug 2010 19:08:37 +0000, dsimcha wrote:
>
>> == Quote from retard (re at tard.com.invalid)'s article
>>> Wed, 25 Aug 2010 14:53:58 -0400, Steven Schveighoffer wrote:
>>> > On Wed, 25 Aug 2010 14:37:33 -0400, Walter Bright
>>> > <newshound2 at digitalmars.com> wrote:
>>> >
>>> >> Steven Schveighoffer wrote:
>>> >>>> Just goes to show how useful a profiler is.
>>> >>>  Yes, I'm glad you pushed me to do it.  Looking forward to the fix.
>>> >>
>>> >> The two secrets to writing fast code are:
>>> >>
>>> >> 1. using a profiler
>>> >> 2. looking at the assembler output of the compiler
>>> >>
>>> >> In my experience, programmers will go to astonishing lengths to
>>> >> avoid doing those two...
>>> >
>>> > You mean like asking someone who reported low performance of your
>>> > program on the newsgroup to do it for you? :)
>>> He forgot:
>>> 0. use a better algorithm (the big O notation matters, like in this
>>> case)
>>
>> Yeah, but unless you use a profiler, how are you going to find those
>> spots where N isn't as small as you thought it would be?
>
> Test-driven develoment, automatic testing tools, common sense? Sometimes
> the profiler's output is too fine-grained.

On the contrary, this was one of those bugs that you almost need a  
profiler for.  Consider that after over 10 years of d compilers nobody has  
found this deficiency until my little library came along.  And even then,  
it's hard to say there actually *is* a problem, the compiler runs and  
outputs valid code, and if you use the -v switch it's continuously doing  
things.  Even when you profile it, you can see that the errant function  
only consumes small chunks of time, but it adds up to an unacceptable  
level.

Test-driven development is only useful if you have a certain criteria you  
expect to achieve.  How do you define how fast the compiler *should* run  
until you run it?  It's a very complex piece of software where performance  
is secondary to correctness.

I can understand not having touched code that outputs an object format for  
20 years.  I don't regularly go through my code looking for opportunities  
to increase big-O performance.

I'm just glad it's been found and will be fixed.

-Steve