search for: p7972

...uot; tasks. The backend work is split about evenly between scanRelocations and OutputSection::writeTo. InputSectionBase::relocate is only about 10% of the total runtime (part of OutputSection::writeTo). Some slightly cleaned up `perf report` output with some more details: https://reviews.llvm.org/P7972 So it seems like overall, the profile is basically split 3 ways (about 30% each): - frontend (reading input files and building the symbol table and associated data structures) - scanRelocations (initial pass over relocations) - writeTo (mostly IO and InputSectionBase::relocate) -- Sean Silva &g...

...evenly between scanRelocations and >> OutputSection::writeTo. InputSectionBase::relocate is only about 10% of the >> total runtime (part of OutputSection::writeTo). >> >> Some slightly cleaned up `perf report` output with some more details: >> https://reviews.llvm.org/P7972 >> >> So it seems like overall, the profile is basically split 3 ways (about >> 30% each): >> - frontend (reading input files and building the symbol table and >> associated data structures) >> - scanRelocations (initial pass over relocations) >> - writeTo...

tl;dr: it looks like we call SymbolBody::getVA about 5x more times than we need to Should we cache it or something? (careful with threads). Here is a link to a PDF of my Mathematica notebook which has all the details of my investigation: https://drive.google.com/open?id=0B8v10qJ6EXRxVDQ3YnZtUlFtZ1k There seem to be two main regimes that we redundantly call SymbolBody::getVA: 1. most