KDE/kdevplatform/shell

[Andreas Pakulat]

On 05.08.09 23:56:39, Friedrich W. H. Kossebau wrote:
> Mercredi, le 5 août 2009, à 17:12, Andreas Pakulat a écrit:
> > On 05.08.09 14:44:04, Friedrich W. H. Kossebau wrote:
> > > Mercredi, le 5 août 2009, à 12:45, Andreas Pakulat a écrit:
> > > > On 05.08.09 02:15:08, Friedrich W. H. Kossebau wrote:
> > > > > SVN commit 1007055 by kossebau:
> > > > >
> > > > > changed: only need a QHash, not a QMap, for the KPart->QWidget
> > > > > storage
> > > >
> > > > Whats the advantage of using QHash instead of QMap here?
> > >
> > > From http://doc.trolltech.com/4.5/qhash.html#details :
> > > * QHash provides faster lookups than QMap
> > >
> > > And IIRC a QHash needs less memory than a QMap, but that is not
> > > guaranteed.
> >
> > Next time, please do profiling first before you do micro-optimizations like
> > this. I don't think the difference is noticeable in KDevelop.
> 
> Yes, seems I really should be more carefully instead of blindly applying Best 
> practises in other people's code :/

I actually didn't mean that you need to revert this change :) Because that
doesn't really add any value. I can't see how either the low speed of QMap
or the higher memory usage of QHash can possibly cause a real difference in
this place.

What I wanted to say is that, changes - even if following best practices -
that do not improve the code itself (as in readability, bugs fixing,
allowing new features) or improve runtime behaviour of the app, should not
be comitted. The simple reason is that it makes it harder to find out why
and who wrote the code. I recently had to do that for something else in
partcontroller and there where 5 different revisions which I needed to
follow to find out where the original code came from and why it was
comitted as it has been.

Andreas

PS: I'm still cc'ing you, but I guess I could turn this off by now and just
reply to the list?

-- 
Time to be aggressive.  Go after a tattooed Virgo.