r209297 - Make the parent-map use significantly less memory.

Manuel Klimek klimek at google.com
Fri May 23 10:05:56 PDT 2014


Fixed in r209530.


On Wed, May 21, 2014 at 6:24 PM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On May 21, 2014, at 9:22 , Manuel Klimek <klimek at google.com> wrote:
>
> On Wed, May 21, 2014 at 6:20 PM, Jordan Rose <jordan_rose at apple.com>wrote:
>
>>
>> On May 21, 2014, at 9:19 , Manuel Klimek <klimek at google.com> wrote:
>>
>> On Wed, May 21, 2014 at 6:10 PM, Jordan Rose <jordan_rose at apple.com>wrote:
>>
>>> You might want to bump up the size of the SmallVector too. Right now
>>> you're dynamically allocating a SmallVector<T, 1>, and immediately putting
>>> two things into it. Alternately, you could use a std::vector, which has a
>>> smaller sizeof itself.
>>>
>>
>> I tried the various combinations, and it didn't make a difference, so I
>> went for making the code the simplest, which was reusing the ParentVector
>> typedef.
>> If we change the ParentVector to a SmallVector<T, 2> we'll also use that
>> for getParents() which mostly returns a single element.
>>
>>
>>
>> SmallVector's already too big to fit in registers, so adding another two
>> words to it won't really hurt any uses on the stack, will it?
>>
>
> So you're proposing to just bump it to 2? I'm happy to do that, but I lack
> any way to get data that would sway me one way or the other, thus I think
> it's mostly guesswork (but I trust your guesswork is probably better than
> mine ;)
>
>
> Well, we don't have that many matcher-based tools, so I'm not that
> familiar with how ParentVector is really used in practice. Dynamically
> allocating a SmallVector that is known to be too small just felt wrong to
> me, is all.
>
> Jordan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140523/c38074e2/attachment.html>


More information about the cfe-commits mailing list