On Thu, 26 Aug 2010 12:53:59 -0400, Walter Bright
<[email protected]> 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.
