GCC with Symbol Visibility patch = faster apps (KDE 3.4)

Question

I've checked gcc CVS PKGBUILD and I can't seem to find this patch in it. The patch is already present in GCC 4.
What is this patch useful for? (quote from here)
1.  It very substantially improves load times of your DSO (Dynamic Shared Object)
      For example, the TnFOX Boost.Python bindings library now loads in eight seconds rather than over six minutes!
   2. 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".
   3. 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!
   4. 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!
What I've understood from that webpage is that, in order to turn this on, the applications must be compiled with some certain flags (this provides GCC backward compatibility, even with this patch applied, IMO).
A comment here states that KDE 3.4 (upcomming version) supports this compile flag and it's (a lot) faster.
I haven't seen the PKGBUILD of KDE 3.4 beta 2 to check if it uses "-fvisibilty=hidden", but I suppose it does not since GCC is not patched.
Fedora, MDK 10.2 and Gentoo have this patch applied to GCC 3.4 (and KDE 3.4 betas are compiled with fvisibility in those distros, according to the comments there.
There's also "-fvisibility-inlines-hidden" which does not require any support from the application, but I think that's overriden by -fvisibility flag.

Answer 1

Well there are plenty of non-kde and kde specific features that are supplied as extras and would only benefit those users that need them (cups, samba, etc) to the rest of the users who may not like, want, or need them they get them anyway right now because in order to not keep recompiling package to add features Arch maintainers add the features in right from the get go. Modularity means that the packages may be built to support such features but will run without the supporting packages and the feature only works or gets enabled when you install the supporting packages.
Take transcode for example it really only has about four true dependencies but it can support all sorts of features all one has to do is install what supporting packages it needs to use these features. thsi allows the user to use whatever features or codecs they like and not have to rebuild in order to use a specific feature. It makess the maintainer's jobs alot easier because they can build all support in with only the minimal dependencies in the end.
Modularity works for all level and need of the user.  The developers of KDE have to know that many users will want it all and many will want a slim KDE that is the nature of the user base in linux. Modularity caters to both.
(Modualrity has been a standard in kernels for years and should be the standard for big projects like kde,gnome, etc.)