Why C++ compiles slowly

[Steven Schveighoffer]

On Thu, 26 Aug 2010 12:53:59 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> Better, now takes 20 seconds vs over 60.  The new culprit:
>>  Flat profile:
>>  Each sample counts as 0.01 seconds.
>>   %   cumulative   self              self     total
>>  time   seconds   seconds    calls  ms/call  ms/call  name
>>  75.79      6.51     6.51     8103     0.80     0.80   
>> TemplateDeclaration::toJsonBuffer(OutBuffer*)
>
> This is most peculiar, as that should have shown up on the previous  
> profile.

I did some more testing.  I think I compiled the profiled version of the  
svn trunk dmd wrong.  This is what happens when you let idiots debug your  
code for you ;)

I recompiled it, and here is the new list:


Flat profile:

Each sample counts as 0.01 seconds.
   %   cumulative   self              self     total
  time   seconds   seconds    calls  ms/call  ms/call  name
  80.31     11.99    11.99    19000     0.63     0.63  searchfixlist
   0.67     12.09     0.10   203173     0.00     0.00   
StringTable::search(char const*, unsigned int)
   0.60     12.18     0.09   369389     0.00     0.00  Lexer::scan(Token*)
   0.54     12.26     0.08   953613     0.00     0.00   
ScopeDsymbol::search(Loc, Identifier*, int)
   0.47     12.33     0.07  1449798     0.00     0.00  calccodsize
   0.40     12.39     0.06   587814     0.00     0.00  code_calloc
   0.40     12.45     0.06    41406     0.00     0.00  pinholeopt
   0.33     12.50     0.05   901563     0.00     0.00  _aaGetRvalue(AA*,  
void*)
   0.33     12.55     0.05   138329     0.00     0.00  reftoident(int,  
unsigned long long, Symbol*, unsigned long long, int)
   0.33     12.60     0.05    26849     0.00     0.00  ecom(elem**)
   0.27     12.64     0.04   230869     0.00     0.00  Type::totym()
   0.27     12.68     0.04    62784     0.00     0.00  touchfunc(int)
   0.27     12.72     0.04    37623     0.00     0.00  optelem(elem*, int)
   0.27     12.76     0.04    28348     0.00     0.00  assignaddrc

It looks like searchfixlist is another linear search, looking back at the  
other profile, it was the second highest consumer of runtime at 2% of the  
runtime before your fix, so it catapulted up to 80% of the runtime.  It  
looks like a linked-list search, so it might benefit from a hash table as  
well?  I'm not really sure.

Also, the 2% was on only one file being compiled, with the shortened run  
time, I was able to build all of dcollections, that's why the # of calls  
for searchfixlist is much higher.

I'll update the bug.