[LLVMdev] Instrumenting the run-time sizes of SmallVector et al.

[David Blaikie]

On Mon, Aug 11, 2014 at 10:53 AM, Hans Wennborg <hans at chromium.org> wrote:
> On Mon, Aug 11, 2014 at 10:35 AM, David Blaikie <dblaikie at gmail.com> wrote:
>> Any chance of performance data as well? After finding a few bugs in
>> SmallVector I am rather curious how much perf SmallVector is giving us
>> & whether it's worth the upkeep/bugs. (it probably is - so it's more
>> something I've been meaning to play with in my spare time as I doubt
>> it'll be fruitful, so I don't expect others to work on it either
>> unless it sounds particularly appealing)
>
> I haven't done any performance measurements, and to be honest I don't
> expect much impact. This was more about me being curious, and the
> general principle of not having inline sizes that are always or almost
> always too small.

Fair point.

> The instances that I fixed typically had a couple of thousand uses
> each during the entire Clang bootstrap, so I estimate that I've
> removed maybe on the order of 100k mallocs during a bootstrap - which
> is nice, but probably not a measurable perf gain overall.
>
> If we had containers with the wrong size that were really hot, they
> would probably have showed up in profiles and been fixed before.

Yep.

(& then we get into "well, if these aren't hot why bother with Small
optimizations, etc, anyway - clearly they don't matter so we should
just use the defaults? I don't really know - should we bother picking
good 'small' sizes for things that don't matter?)

But, yes, best not to waste stack space on incorrect small sizes,

- David

>
>  - Hans
>
>> On Sun, Aug 10, 2014 at 7:23 PM, Hans Wennborg <hans at chromium.org> wrote:
>>> I've always wondered how the in-line sizes of SmallVector,
>>> SmallString, etc. that we use in LLVM and Clang hold up against the
>>> actual sizes of the containers at run-time.
>>>
>>> To figure this out, I added a destructor to each such class, that
>>> would dump the container's final size into a table that got printed at
>>> exit. I also added a special field, __clang_ObjectLocation, to each
>>> such class and hacked Clang to populate that field with the source
>>> location of the object's declarator each time its constructor was
>>> called.
>>>
>>> I used this instrumented compiler to build vanilla Clang and captured
>>> the results (attached, along with the patches I used). It looks like
>>> we mostly get it right, but I have patches for a few size tweaks I'd
>>> like to do. (The measurements were done on Clang r215325 / LLVM
>>> r215315).