Bug 4900 – compiler still slow due to a single function
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
Other
OS
Linux
Creation time
2010-09-20T05:20:20Z
Last change time
2019-07-16T04:22:41Z
Keywords
performance
Assigned to
No Owner
Creator
Steven Schveighoffer
Comments
Comment #0 by schveiguy — 2010-09-20T05:20:20Z
As shown in bug 4721, there is still a problem in the compiler when compiling projects with a large number of symbols. Here is a profiled version of dmd 2.048 compiling unit tests for dcollections:
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
...
Note the searchfixlist function uses 80% of the runtime (the compiler takes 17 seconds to produce a result), but only has 19000 calls. Compare that to other functions which have orders of magnitude more calls but nothing takes more than 0.7%.
An examination of the searchfixlist function shows that it is a search through a linked list. I'm unsure if the same methodology (replace with hash) can be applied as was in issue 4721, but it would be good to investigate possible ideas to replace the algorithm there.
I opened this as a separate bug, because the original bug in 4721 was fixed.
Comment #1 by bugzilla — 2010-11-23T12:57:31Z
Yes, the linked list should be replaced with a hashtable.
Comment #2 by bearophile_hugs — 2010-11-25T20:19:58Z
See also bug 5276 for another possible (smaller) benchmark.
Well, I certainly have tested dcollections since then, but I don't remember there being a significant speedup.
I'd have to re-profile the compiler to be sure.
Comment #5 by pro.mathias.lang — 2019-07-16T04:22:41Z