koffice/krita/benchmarks

[Dmitry Kazakov]

On Mon, Jan 25, 2010 at 12:15 PM, Boudewijn Rempt wrote:

> 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.
>

Yeah, no checking, it just makes me think too much when i'm trying to
calculate the size of manually created arrays =)
You can use filled arrays instead of hakonepa of course. But you need to
split the time of allocation and reading/writing - that's the point.


> 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


> 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 benchmark tests first writing real data, then reading real
> 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.


>
> > 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?
>

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


>
> > 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 don't think so. If it don't cause more severe bugs... Nevertheless, it's
not that much time to fix.


>
> > 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
> >
>
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>



-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100125/f9facf50/attachment.htm