koffice/krita/benchmarks

[Boudewijn Rempt]

On Mon, 25 Jan 2010, Dmitry Kazakov wrote:

> Hah.. These results are quite unobjective =) You were reading and writing
> 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 of
pixels is all the same as the default pixel? I can't find any code in the
writeBytes codepath that does that, so I am fairly sure that we are filling tiles
with pixels in the benchmark.

So I think the writeBytes benchmark tests allocating tiles and filling the tiles
with data, the readBytes benchmark tests reading the default tile, the readWrite
benchmark tests first writing real data, then reading real data.
 
> 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 (remember,
> that tiles3 still has "extents"-bug)

Do you have any prognosis for a fix for that?

> For tiles/
> 1) speed of reading of the default tile, that is preallocated inside dm
> 
> 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 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 result.
> 
> 6) Btw, we should test Memento mechanism:
>      o write-getMemento-repeat
>      o read-write-read-getMemento-repeat

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