<div class="gmail_quote">On Mon, Jan 25, 2010 at 12:15 PM, Boudewijn Rempt wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Mon, 25 Jan 2010, Dmitry Kazakov wrote:<br>

<br>
&gt; Hah.. These results are quite unobjective =) You were reading and writing<br>
&gt; empty pixels, that is a special case in both managers. And doesn&#39;t show<br>
&gt; actual read/write speed. Though shows a different thing...<br>
<br>
</div>Does any tile engine actually check whether the contents of a block of<br>
pixels is all the same as the default pixel? I can&#39;t find any code in the<br>
writeBytes codepath that does that, so I am fairly sure that we are filling tiles<br>
with pixels in the benchmark.<br></blockquote><div><br></div><div>Yeah, no checking, it just makes me think too much when i&#39;m trying to calculate the size of manually created arrays =)</div><div>You can use filled arrays instead of hakonepa of course. But you need to split the time of allocation and reading/writing - that&#39;s the point.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">So I think the writeBytes benchmark tests allocating tiles and filling the tiles<br>
with data, </blockquote><div>Yes. And as no transaction was created, there is no memento&#39;ing</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">the readBytes benchmark tests reading the default tile,</blockquote>
<div>Exactly! Do you know any real-life benefit of reading default tile? ;) I&#39;d better know actual read-time instead.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
 the readWrite benchmark tests first writing real data, then reading real data.<br></blockquote><div>This result is the nearest to the real-world one, but it is dirtied by 1/100th of allocation time and doesn&#39;t show separate read and write times.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
&gt; Writing of pixels to the empty dm shows in both engines:<br>
&gt; 1) speed of allocation of a new tile<br>
&gt; 2) speed of filling this tile with data<br>
&gt;<br>
&gt; Reading from the empty dm shows different things for both engines (remember,<br>
&gt; that tiles3 still has &quot;extents&quot;-bug)<br>
<br>
</div>Do you have any prognosis for a fix for that?<br></blockquote><div><br></div><div>After walkers finished and synchronization between image&lt;-&gt;ui done. And i promised Edward to fix some bug in tiles3 after walkers, iirc...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
&gt; For tiles/<br>
&gt; 1) speed of reading of the default tile, that is preallocated inside dm<br>
&gt;<br>
&gt; For tiles3/<br>
&gt; 1) speed of allocation of a new tile<br>
&gt; 2) speed of reading this tile<br>
&gt; This should be fixed of course, but i&#39;m still trying to find time for that.<br>
<br>
</div>It&#39;s sort of a blocker for 2.2, I think.<br></blockquote><div><br></div><div>I don&#39;t think so. If it don&#39;t cause more severe bugs... Nevertheless, it&#39;s not that much time to fix.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
&gt; I thing &quot;nominations&quot; should be the following:<br>
&gt;<br>
&gt; 1) Reading:<br>
&gt; load some image (e.g. hakonepa or smth bigger), and read it<br>
&gt; 2) Writing:<br>
&gt; write hakonepa to dm<br>
&gt; 3) Clearing:<br>
&gt; clear(someColor) - this should be much faster in new engine<br>
&gt; 4) Reading *empty* dm - reveals my bug<br>
&gt; 5) Writing *empty* dm. If we subtract 2nd number form this, we&#39;ll get pure<br>
&gt; time of allocation of new tiles. This should be very interesting result.<br>
&gt;<br>
&gt; 6) Btw, we should test Memento mechanism:<br>
&gt;      o write-getMemento-repeat<br>
&gt;      o read-write-read-getMemento-repeat<br>
<br>
</div>Yes, the memento performance should be benchmarked as well.<br>
&gt;<br>
&gt; --<br>
&gt; Dmitry Kazakov<br>
&gt;<br>
<br>
_______________________________________________<br>
kimageshop mailing list<br>
<a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Dmitry Kazakov<br>