llvm dev - Aug 2014 - [LLVMdev] Instrumenting the run-time sizes of SmallVector et al.

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

Cheers,
Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang.patch
Type: text/x-patch
Size: 2837 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140810/84f35bc2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm_adt.patch
Type: text/x-patch
Size: 6422 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140810/84f35bc2/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: results.txt.gz
Type: application/x-gzip
Size: 25657 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140810/84f35bc2/attachment-0002.bin>

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)

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).
>
> Cheers,
> Hans
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

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