+1. Not very many people know C++ internals well
enough to really know
what is going on with visibility support.
I'm studying C++ on my own but have a long, long, long way to go. I'm getting so I
can at least read C++ code without crying or running my finger up and down across my lips.
:)
I understand that the ELF standard basically describes the way files are structured
internally in order to knowably find what is needed. I can see that reducing the size of
any file theoretically helps with loading and run times, but by how much I have no clue.
:)
The claims on that website are a bit overinflated (to
their
credit they
did state this). My testing on TDE has indicated a
slight but noticeable
speed increase with something like a 10% decrease in core
library size.
To be fair this test was run on a heavily loaded
development system over
NFS, so a lightly used system with lots of RAM and a fast
hard disk may
notice no speed improvement at all.
What about systems with nominal RAM and slow hard disks --- old systems?
TDE needs to be built with the visibility flag set
for
arts, tdelibs, and
tdebase to see the improvements. I would treat this
flag as beta quality
for now until we get widespread testing of the resultant
code, as older
versions (3.x) of gcc had problems implementing visibility
support on KDE.
I'm game for the experiment. I'm back porting the patches to 3.5.13 too.
I hope this helps some!
Yes. Thank you! :)
Darrell