Iterator benchmark

Dmitry Kazakov dimula73 at gmail.com
Mon Jun 8 23:05:33 CEST 2009


I'm going to take a look at iterators and optimize them for the actual
data-manager after modifying data-manager itself =)

When i was profiling processors i got that plenty of time spent on
intersecting QRects, constructing QPoints and etc. Throwing them away
took me additional 5% of efficiency (but it didn't help processors,
all the same =) ). (Yes, KisShared takes much too)

Some optimization was achieved thanks to avoiding dereferencing
(members of classes were thrown away from cycles):

int pixelSize = m_pixelSize;
for(...) {
    ...=pixelSize;
}

And old readPlanarData were too slow because of massive calling of
QVector::operator[], but you've read that :)


On Tue, Jun 9, 2009 at 12:46 AM, Sven Langkamp<sven.langkamp at gmail.com> wrote:
> Hi,
>
> I have commited a first version of the iterator benchmark we dicussed
> yesterday. It basically iterates over a paint device without doing memcpys.
> The results are as we expected:
>
> -HLine- and VLineIterator perform quite similar.
> -the rect iterator about 10% faster than hline
> -the random accesor is about 40% slower than hline
>
> I tried callgrind on it, but for some reason it doesn't work that good
> (maybe because of the unit test) and it's really slow. Any idea if it's
> possible to speed it up a bit?
>
>
> Sven
>
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>



-- 
Dmitry Kazakov


More information about the kimageshop mailing list