+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