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

[Hans Wennborg]

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.

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.

 - 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).