this morning while brushing my teeth i remembered an interview i read with some of the PostgreSQL developers around the time of one of the 7.x releases. the interviewer noted how much faster PostgreSQL was compared with an earlier 7.x version and especially when compared to the 6.x series, and asked what they had done to achieve these results. a developer responded that there wasn't any specific development in particular that had caused this speeed boost. rather, they had made a 1% improvement here, and a .5% improvement there, etc. eventually these little optimizations piled up across the code base and their combined weight created a noticeable improvement. a lack of obvious optimization targets led to a holistic approach of "improve whatever you can, even if it seems trivial right now."
coming up on KDE 3.4 and KDE 4.0 after that, i think we're in a similar situation to the PostgreSQL developers above. Qt4 may give us some nice speed boosts and lower our memory consumption in KDE4 "for free" (though the impact of Qt4 is yet to be seen and measured), but we have a large codebase in kdelibs and kdebase that forms the "base KDE platform" that we have complete control over. there may not be any single stretch of code that is needlessly responsible for 5% of execution time, but i be we can find 50 places that are each responsible for 0.1% of execution time that can be optimized.
a nice thing about this approach is that it doesn't require much distraction from other development efforts. improve what's near, and we'll see a cumulative improvement.
(p.s. i'm not suggesting radical, code-uglifying micro-optimizations be applied everywhere, as maintainability and reliability are equally important. but our code base isn't so tight that those are our only optimization possibliities.)