[PATCH] MCObjectSymbolizer

[Sean Silva]

On Mon, Oct 14, 2013 at 8:02 PM, Stephen Checkoway <s at pahtak.org> wrote:

>
> On Oct 14, 2013, at 7:59 PM, Sean Silva <silvas at purdue.edu> wrote:
>
> > On Mon, Oct 14, 2013 at 6:49 PM, Stephen Checkoway <s at pahtak.org> wrote:
> >
> >> MCObjectSymbolizer currently iterates through each symbol every time it
> is
> >> asked to tryAddingSymbolicOperand. With many symbols, this takes a very
> >> long time.
> >>
> >
> > I ran into an issue this summer where `llvm-objdump -symbolize` took like
> > 10,000 times longer than without. Is this related to that?
>
> I was using -symbolize.
>
> >> The attached patch iterates through the symbols the first time this is
> >> needed and puts them in a sorted vector. Subsequent lookups use
> >> std::upper_bound() to find the symbol in log(n) time.
> >>
> >> Without the patch, calling MCObjectDisassembler::buildModule(/* withCFG
> */
> >> false) on an unstripped build of Chromium took more than 2 hours (which
> is
> >> when I gave up on it). With the patch, it takes 24 seconds.
> >>
> >> My particular build of Chromium has 474,222 symbols (as counted with nm
> >> chrome|wc -l) and is 2.1 GB.
> >>
> >> It is difficult to test the speedup with llvm-objdump because passing
> true
> >> for withCFG uses more than my available 32 GB of RAM when run on a 7.3
> MB
> >> file and on smaller files, e.g., my 3 MB ninja binary, the difference in
> >> speed is in the noise. And even then, it's using about 6 GB of RAM.
> >>
> >
> > What command line for llvm-objdump uses 6GB of RAM on the ninja binary?
> > That seems bug-worthy; the ninja executable is like <200K of code (the
> rest
> > is debug info, which ninja builds with by default).
>
>
> llvm-objdump -disassemble -cfg -symbolize ninja
>

Holy crap! Have you investigated what is using so much memory?

-- Sean Silva


>
> --
> Stephen Checkoway
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131014/2bdff0d8/attachment.html>