[llvm] r240733 - AsmPrinter: Convert DIE::Values to a linked list

[Duncan P. N. Exon Smith]

> On 2015-Jun-25, at 17:09, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Thu, Jun 25, 2015 at 5:07 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> On Thu, Jun 25, 2015 at 4:46 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> Author: dexonsmith
> Date: Thu Jun 25 18:46:41 2015
> New Revision: 240733
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=240733&view=rev
> Log:
> AsmPrinter: Convert DIE::Values to a linked list
> 
> Change `DIE::Values` to a singly linked list, where each node is
> allocated on a `BumpPtrAllocator`.  In order to support `push_back()`,
> the list is circular, and points at the tail element instead of the
> head.  I abstracted the core list logic out to `IntrusiveBackList` so
> that it can be reused for `DIE::Children`, which also cares about
> `push_back()`.
> 
> This drops llc memory usage from 799 MB down to 735 MB, about 8%.
> 
> Just looking at the core of this change - where exactly are the memory savings:
> 
> -  SmallVector<DIEValue, 12> Values;
> +  DIEValueList Values;
> 
> Is it just that most DIEs don't have that many values? If we had a lower small vector size I would imagine it'd be smaller than a linked list - paying a pointer in every value compared to paying one pointer and one size to point to all the values? (with any DIE with more than two values that would be efficient - more than 3 and we could have buffer pointer + size + capacity and still be winning, no?) Do most DIEs have fewer attributes? Most I can think of have more than 3... 
> 
> Presumably I've missed something about how this is a win over alternatives.
> 
> I guess it's the bump pointer allocation performance wins (might be worth documenting those to, to help justify the change so someone coming back to this doesn't decide to change it back for greater memory wins but hurting compile time) that wouldn't be practical to get with a vector-like scheme? 

Good idea, documented in r240868.

There's a histogram here, for reference:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/085910.html

The bump pointer allocation is part of it, but also the singly list
list is itself fairly memory efficient.

Note that because vectors tend to be over-allocated by ~50%, the bump
pointer allocated singly linked list node doesn't really take extra
memory; on x86-64, the node is 3 pointers vs. 2, also 50%.

Unless you have a pretty specific histogram, SmallVector is slightly
heavier than a vector: on top of paying for the 3ptrs and the actual
allocation (which is ~50% too big), you're potentially paying for the
empty/unused "small" storage.  You can combat this by making the
"small size" really large, but then the static allocation is usually
way more than necessary.  Bloated either way, AFAICT (again, unless
you have a fairly specific histogram... and I'm also ignoring the
non-zero overhead of a malloc allocation, but we're comparing to bump
pointer allocated linked lists after all).