[PATCH] Change MCTextAtom to use std::list instead of std::vector

Chandler Carruth chandlerc at google.com
Tue Oct 15 11:43:18 PDT 2013


Have you looked into the LLVM ilist? Its intrusive and so should be a touch
faster and a touch more memory dense than std::list.


On Tue, Oct 15, 2013 at 11:27 AM, Stephen Checkoway <s at pahtak.org> wrote:

> Changing MCTextAtom to use a list instead of a vector reduces the memory
> usage of running llvm-objdump -disassemble -symbolize -cfg ninja from 16 GB
> to 9 MB.
>
> I believe the problem is that erasing elements from the vector doesn't
> free up any space so each time an atom is split, we still have all the
> space for those instructions.
>
> Using a list also enables us to use std::list::splice() to split the
> instructions in constant time. There is still a linear scan to find the
> split point.
>
> Maybe something could be done using smarter data structures or smarter
> choices of the order atoms are split, but I haven't gone down that route.
>
> One consequence of switching to a list is that the MCTextAtom::at()
> function becomes inefficient since you would need to perform the linear
> scan. However, this is only used in two locations: MCModuleYAML and
> llvm-objdump. In both cases, the code was iterating over every instruction
> so the patch changes the loops to use iterators and MCTextAtom::at() is
> removed.
>
> The patch could be split into two parts, one that changes from vector to
> list and fixes the two at() uses, and one that replaces the copy() +
> erase() with splice().
>
> I still run out of memory trying to run it on my chromium with debug
> symbols but as Ahmed pointed out, there is probably room for improvement
> still. (A singly linked list would save some but C++98 doesn't appear to
> have one and there are probably better optimizations.)
>
> --
> Stephen Checkoway
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131015/b8882d54/attachment.html>


More information about the llvm-commits mailing list