10 Jan
2012
10 Jan
'12
9:58 p.m.
On 10 January 2012 16:42, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
I understand the distinction between public and
private variables and
functions. I don't have a grasp about why this gcc visibility thing makes a
difference.
Why is enabling this good for me as a builder/packager?
As an end-user?
I get the feeling with hiding the private non shared stuff that
executables and libraries are smaller in size, which theoretically reduces
load times, which theoretically should improve response on the desktop. But
how much?
A layman's explanation is much appreciated. :)
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-users-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-users-help(a)lists.pearsoncomputing.net
Read list messsages on the Web archive:
http://trinity-users.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
10 seconds on google:
from: http://gcc.gnu.org/wiki/Visibility
Put simply, it hides most of the ELF symbols which would have previously
(and unnecessarily) been public. This means:
-
*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!
Although the library quoted above is an extreme case, the new visibility
support reduced the exported symbol table from > 200,000 symbols to less
than 18,000. Some 21Mb was knocked off the binary size as well!