optimizing & api-doc

[Lubos Lunak]

On Thursday 16 of January 2003 15:18, Michael Olbrich wrote:
> Hi,
>
> I've followed the discussion here quite some time now, and I'm missing
> the kde related parts a bit. It's kde-optimize after all. I know there
> are issues with the linker etc. but we can't to much about that. And I
> think we have better things to do here, than discussing which hack
> improves the situation most. These hacks may help us, but not those who
> need a stable environement, or don't have the time/knowlede to use them.
>
> From what I've seen, many speed problems within c++ programs have their
> origin in the language. In c++ it's easy to hide complexity. This helps
> to have a clean design, and makes the developers productive. But the
> complexity is still there and can make the programs slow.
>
> So what I'm missing here, and this is true for both, kde and qt api
> documentation, are hints about the complexity of methods, etc. e.g. mark
> methods, that shouldn't be called to often, or when overloading a
> function, which one is fast, which is slow. QString::find comes to my
> mind here.
>
> I think, things like this can help writing faster code while keeping it
> simple and clean.

 The list is up for how long, a week? What did you expect, a complete 
optimalization guide, and KDE running ten times faster? Nobody said the main 
purpose of this list is to create the ultimate KDE optimalization guide for 
everybody. If it will just help cooperating developers working on various 
specific optimalizations in KDE, and various howto's appear as side-effects 
of it, then I'll be more than happy with this list.

 This list is for whatever is related to improving KDE performance. If people 
find the linker problems important, why not discussing it here? If you think 
what you proposed is important, feel free to start working on it.

 BTW, I personally think comparing performance of QString::find() varians 
won't give many benefits. I'd expect the more powerful (regexp) one to be the 
slowest, the least powerful (q/char) to be the fastest, and people using the 
best fitting for their purpose. If you want to analyze such incorrect uses of 
API, I'd rather suggest analyzing usage patterns that just simple functions. 
I'd bet that e.g. finding out that mixing QImage and QPixmap makes code slow 
can lead to much more noticeable improvements that comparing QString::find().

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/