On attribute inference...

Johannes Pfau via Digitalmars-d digitalmars-d at puremagic.com
Tue Apr 19 04:47:34 PDT 2016


Am Tue, 19 Apr 2016 01:57:21 -0700
schrieb Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com>:

> I expect that hiding symbols which aren't public would certainly help
> a great deal in avoiding having a lot of unnecessary symbols in a
> compiled library, but it doesn't completely solve the problem. And
> when discussions on export have come up, some of the folks who are
> particularly knowledgeable on the subject have been _very_ much in
> favor of using export to restrict what is and isn't visible in the
> generated library rather than relying on public. They'll have to
> chime in to provide good details though. The main issue that I recall
> is the desire/need to reduce the number of symbols in order to make
> compiling/linking more efficient.
> 
> - Jonathan M Davis
> 

Not only compiling / linking: https://gcc.gnu.org/wiki/Visibility

* It very substantially improves load times of your DSO (Dynamic Shared
  Object). For example, a huge C++ template-based library which was
  tested (the TnFOX Boost.Python bindings library) now loads in eight
  seconds rather than over six minutes!

* It lets the optimiser produce better code. PLT indirections (when a
  function call or variable access must be looked up via the Global
  Offset Table such as in PIC code) can be completely avoided, thus
  substantially avoiding pipeline stalls on modern processors and thus
  much faster code. Furthermore when most of the symbols are bound
  locally, they can be safely elided (removed) completely through the
  entire DSO. This gives greater latitude especially to the inliner
  which no longer needs to keep an entry point around "just in case".

* It reduces the size of your DSO by 5-20%. ELF's exported symbol table
  format is quite a space hog, giving the complete mangled symbol name
  which with heavy template usage can average around 1000 bytes. C++
  templates spew out a huge amount of symbols and a typical C++ library
  can easily surpass 30,000 symbols which is around 5-6Mb! Therefore if
  you cut out the 60-80% of unnecessary symbols, your DSO can be
  megabytes smaller!

* Much lower chance of symbol collision. The old woe of two libraries
  internally using the same symbol for different things is finally
  behind us with this patch. Hallelujah! 


More information about the Digitalmars-d mailing list