On Sunday 15 May 2005 15:33, Duncan wrote: > > BTW, haven't done any hard number comparisons, but I do run a memory > monitor sysguard applet in kicker, and if I'm not mistaken, the system > with the new glibc seems to be taking ~50MB less memory, also, perhaps > 75MB less. Note that the glibc ebuild forces -O2 and strips nearly all > other CFLAGS. Performance doesn't feel different with the gcc4 compiled > glibc, altho as I noted earlier, kde is DEFINITELY faster on the loadup > since I recompiled most of the major parts of it with gcc4, probably due > to the use of the new gcc4 visibility-hidden stuff used for all those > intended for internal use only functions, which don't need scanned for > linking now. > I just wanted to point out that the visibility support is also in GCC 3.4 (it was backported in our version), and will soon be disabled due to segfaults it produces, after discussions with the KDE developers on the issue. You can find bugs in our bugzilla, and the KDE bugzilla if you would like more information.
Using GCC 4 certainly shouldn't cause any major improvement in speed due to visibility though, as it was already available in 3.4.*. I am of course always interested in the progress, and am also testing GCC 4 with a mainly KDE based desktop system. It was however acknowledged by the GCC developers that the biggest speed improvements would likely appear in 4.1 and later. The snapshots available in portage should get rid of the issues KDE was having. I intend test KDE 3.4.1 with GCC 4 once it is released. -- Gentoo Linux Developer Scientific Applications | AMD64 | KDE | net-proxy
pgpsIs4LUGBvv.pgp
Description: PGP signature
