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
clang.patch (2.77 KB)
llvm_adt.patch (6.27 KB)
results.txt.gz (25.1 KB)
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)
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
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