llvm dev - Dec 2015 - Memory utilization problems in profile reader

On Fri, Dec 11, 2015 at 9:58 AM, Diego Novillo <dnovillo at google.com>
wrote:
> So, I traced it down to the DenseMaps in class FunctionSamples.  I've
> replaced them with two std::vector, and the read operation causes the
> compiler to grow from 70Mb to 280Mb.  With the DenseMaps, reading the
> profile causes the compiler to grow from 70Mb to 3Gb.
>
> Somehow the DenseMaps are causing a 10x growth factor.  Those keys are
> probably an issue.  Or perhaps we just need a different representation for
> sample records and call sites.
>
Yes. In going through DenseMap's implementation I see that large values for
keys will cause a lot of growth.  And the documentation confirms it
(someday I'll learn to read documentation first).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151211/ae465acd/attachment.html>

On Fri, Dec 11, 2015 at 7:53 AM, Diego Novillo via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Fri, Dec 11, 2015 at 9:58 AM, Diego Novillo <dnovillo at
google.com>
> wrote:
>
>> So, I traced it down to the DenseMaps in class FunctionSamples. 
I've
>> replaced them with two std::vector, and the read operation causes the
>> compiler to grow from 70Mb to 280Mb.  With the DenseMaps, reading the
>> profile causes the compiler to grow from 70Mb to 3Gb.
>>
>> Somehow the DenseMaps are causing a 10x growth factor.  Those keys are
>> probably an issue.  Or perhaps we just need a different representation
for
>> sample records and call sites.
>>
>
> Yes. In going through DenseMap's implementation I see that large values
> for keys will cause a lot of growth.  And the documentation confirms it
> (someday I'll learn to read documentation first).
>
I agree, it's a pretty major pitfall. It'd be nice if DenseMap used
std::unique_ptr or something under the hood for value types over a certain
size.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151211/b86de71d/attachment.html>

Isn't that ironic as 'Dense' should mean small and compact?  Can
that be
fixed?

David

On Fri, Dec 11, 2015 at 7:53 AM, Diego Novillo <dnovillo at google.com>
wrote:
>
>
> On Fri, Dec 11, 2015 at 9:58 AM, Diego Novillo <dnovillo at
google.com>
> wrote:
>
>> So, I traced it down to the DenseMaps in class FunctionSamples. 
I've
>> replaced them with two std::vector, and the read operation causes the
>> compiler to grow from 70Mb to 280Mb.  With the DenseMaps, reading the
>> profile causes the compiler to grow from 70Mb to 3Gb.
>>
>> Somehow the DenseMaps are causing a 10x growth factor.  Those keys are
>> probably an issue.  Or perhaps we just need a different representation
for
>> sample records and call sites.
>>
>
> Yes. In going through DenseMap's implementation I see that large values
> for keys will cause a lot of growth.  And the documentation confirms it
> (someday I'll learn to read documentation first).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151211/6475cadd/attachment.html>

On Fri, Dec 11, 2015 at 8:58 AM, Xinliang David Li via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Isn't that ironic as 'Dense' should mean small and compact? 
Can that be
> fixed?
>
I think, at the time it was written, the goal was to improve on std::map
for small data types, so it is "dense" in the sense that it does not
fragment the heap.

We also have this naming problem for SmallVector and TinyPtrVector. These
data types both claim to use less memory, but they are optimized in
different directions. TinyPtrVector is minimizes object size so that it can
be used efficiently in DenseMap, while SmallVector increases the object
footprint to avoid heap allocations in favor of stack allocations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151211/793dacd1/attachment.html>