Re: [boost] [Booster] Or boost is useless for library developers

Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: Kim Barrett (kab.conundrums_at_[hidden])
Date: 2010-05-20 15:31:37

On May 20, 2010, at 1:23 PM, Lassi Tuura wrote:
>>> - Inline functions is best way to improve performance.
>> I've found this to be true in my own work. So have lots of other people. Prove us wrong.
> 
> Let me have a go at describing some bloat. It's not in my interest to prove anything. I'll just tell you cost we see in real-life applications.
> 
> On Linux, GCC 4.5.x, x86_64, we have executables which load 598 DSO images mapped in 611 memory regions, corresponding to:
> 
> [... snipped detailed breakdown ...]
> That's ~55% "real stuff", ~25% of symbol tables, ~10% unwind tables, ~10% relocations and PLT. [...]
> 
> There are 544'533 symbols which represent 142'548'100 bytes. Of this there are 272'190 weak symbols, or 43'565'063 bytes.

Any idea how much of the symbol space would go away with proper application of symbol visibility, such as defaulting to hidden and only exposing those that are needed? I realize that's hard to measure without actually having gone through the exercise of getting all that stuff done right, which may be quite hard in some cases (especially when dealing with third-party code). See the currently ongoing thread with subject "GCC symbol visibility across shared libraries". 

A while ago I did some work on reducing the size of our boost.python-based wrapper libraries. I wasn't able to make any progress using the symbol visibility controls, as there was too much underlying work that needed to be done. However, I was able to achieve a > 50% reduction in the size of these libraries by using linker scripts that encoded a few simple heuristics.