> +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