On Mon, Jan 25, 2010 at 12:15 PM, Boudewijn Remp= t wrote:

On Mon, 25 Ja= n 2010, Dmitry Kazakov wrote:

> Hah.. These results are quite unobjective =3D) You were reading and wr= iting
> empty pixels, that is a special case in both managers. And doesn't= show
> actual read/write speed. Though shows a different thing...

Does any tile engine actually check whether the contents of a block o= f
pixels is all the same as the default pixel? I can't find any code in t= he
writeBytes codepath that does that, so I am fairly sure that we are filling= tiles
with pixels in the benchmark.

Yeah, no = checking, it just makes me think too much when i'm trying to calculate = the size of manually created arrays =3D)

You can use filled array= s instead of hakonepa of course. But you need to split the time of allocati= on and reading/writing - that's the point.

=C2=A0

So I think the writeBytes = benchmark tests allocating tiles and filling the tiles
with data,

Yes. And as no transaction was created, there = is no memento'ing

=C2=A0

the readBytes benchmark tests reading the default tile,

Exactly! Do you know any real-life benefit of reading default tile? ;)= I'd better know actual read-time instead.

the readWrite=C2=A0benchmark tests first writing real data, then reading r= eal data.

This result is the nearest to the real-world= one, but it is dirtied by 1/100th of allocation time and doesn't show = separate read and write times.

=C2=A0

> Writing of pixels to the empty dm shows in both engines:
> 1) speed of allocation of a new tile
> 2) speed of filling this tile with data
>
> Reading from the empty dm shows different things for both engines (rem= ember,
> that tiles3 still has "extents"-bug)

Do you have any prognosis for a fix for that?

After walkers finished and synchronization between image<-&= gt;ui done. And i promised Edward to fix some bug in tiles3 after walkers, = iirc...

=C2=A0

> For tiles/
> 1) speed of reading of the default tile, that is preallocated inside d= m
>
> For tiles3/
> 1) speed of allocation of a new tile
> 2) speed of reading this tile
> This should be fixed of course, but i'm still trying to find time = for that.

It's sort of a blocker for 2.2, I think.

I don't think so. If it don't cause more severe bugs...= Nevertheless, it's not that much time to fix.

=C2=A0

> I thing "nominations" should be the following:
>
> 1) Reading:
> load some image (e.g. hakonepa or smth bigger), and read it
> 2) Writing:
> write hakonepa to dm
> 3) Clearing:
> clear(someColor) - this should be much faster in new engine
> 4) Reading *empty* dm - reveals my bug
> 5) Writing *empty* dm. If we subtract 2nd number form this, we'll = get pure
> time of allocation of new tiles. This should be very interesting resul= t.
>
> 6) Btw, we should test Memento mechanism:
> =C2=A0 =C2=A0 =C2=A0o write-getMemento-repeat
> =C2=A0 =C2=A0 =C2=A0o read-write-read-getMemento-repeat

Yes, the memento performance should be benchmarked as well.
>
> --
> Dmitry Kazakov
>

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop