<br><br><div class="gmail_quote">On Wed, Jun 10, 2009 at 1:56 PM, Cyrille Berger <span dir="ltr"><<a href="mailto:cberger@cberger.net">cberger@cberger.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="font-family: 'DejaVu Sans'; font-size: 9pt; font-weight: 400; font-style: normal;"><div class="im">On Monday 08 June 2009, Sven Langkamp wrote:<br></div><div><div></div><div class="h5">
> Hi,<br>
><br>
> I have commited a first version of the iterator benchmark we dicussed<br>
> yesterday. It basically iterates over a paint device without doing memcpys.<br>
> The results are as we expected:<br>
><br>
> -HLine- and VLineIterator perform quite similar.<br>
> -the rect iterator about 10% faster than hline<br>
> -the random accesor is about 40% slower than hline<br>
><br>
> I tried callgrind on it, but for some reason it doesn't work that good<br>
> (maybe because of the unit test) and it's really slow. Any idea if it's<br>
> possible to speed it up a bit?<br>
><br>
><br>
> Sven<br></div></div>
I runned it with callgrind, since it takes 20 minutes, you can get the file here [1].<br>
<p style="margin: 0px; text-indent: 0px;"><br></p>I didn't do a full analysis yet, but there is something fishy, I think the random accessor should have the same performance as the line iterator (a little bit more slow since there is more checking in the accessor than iterator, and the cache doesn't help since it only caches four tiles (main use of the cache was/is for the sub random accessor). And I noticed something definitively wrong, the random accessor call twice as more fetchTiles as the h/v iterators do. Either there is something wrong in the benchmark (but couldn't see it) or a bug in the accessor. I will need to investigate more.<br>
<p style="margin: 0px; text-indent: 0px;"><br></p>[1] <a href="http://cyrille.diwi.org/tmp/krita/callgrind.out.10663" target="_blank">http://cyrille.diwi.org/tmp/krita/callgrind.out.10663</a><br></div></blockquote><div><br>
I have attached a patch to fix that. Can you review it? The problem is that the area of the cached tile is assumed as one pixel smaller than it actually is which lead to a tile fetch on the last pixel.<br></div></div>