[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Speed of Krita 2.4
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2011-08-01 21:42:35
Message-ID: CAAmsBf=Jqx=WbaCphvfU_Gd8WbwgL_R5=qaMnrEt=i4_6jqXwQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Jul 30, 2011 at 11:41 AM, Silvio Heinrich <plassy@web.de> wrote:
> Am 29.07.2011 23:30, schrieb JL VT:
> > I don't know how fast Krita is in the other branches (I haven't tested)
> > however I'd like to ask if there's a good date to start feeling really
> > worried about speed?, I don't want 2.4 to be a single bit slower than
> > 2.3, so I'd like to start hacking to try to find where our current
> > bottlenecks are; but I don't know which parts deep in Krita to touch
> > without stepping on other developer's toes, moreover, my fears may be
> > unfounded, maybe we're just a couple weeks shy of a branch merge solving
> > all these problems, but, again, I haven't kept up enough with our IRC
> > backlogs and Krita branches to be sure.
> >
> > Should I be worried?.
> >
> > Is there an upcoming branch I should be testing to help with the speed
> > bottlenecks instead?.
> >
>
> As far as I know we have two big bottle necks.
> The first is the creation and transformation (rotation, scaling) of the
> brush masks. The last time I profiled krita it spent 20-30% (I can't
> remember exactly anymore) of the whole processing time while painting
> with this operations.
>
Depends on which brush is used. Autobrush shows about 30% of the time in
processing the mask, but it's not using 100% cpu. I think there is another
bottleneck that callgrind doesn't show. Painting with predefined brushes
shows a big performance bottleneck in scaling the brush (callgrind file:
http://depot.tu-dortmund.de/get/syvg6 ) in the stroke benchmark. There is a
single method that takes most of the time, so that should be the first
target when trying to speed up things.
> The second one is the huge memory consumption of krita. I think it would
> be unlikely that the process of painting itself gets faster with a lower
> memory consumption but the overall execution of krita.
> If a lot of memory is used (and I'm talking about gigabytes) the OS
> needs a lot more processing time to manage the memory what makes krita
> slower too. And its not uncommon that you reach the memory limit of your
> system when using krita. I often have 2-4GBs in use.
>
Most of the memory consumption is used to speed up things e.g. all the
projection are using a huge amount of memory but save processing power that
would be needed to recalculate them.
[Attachment #5 (text/html)]
<div class="gmail_quote">On Sat, Jul 30, 2011 at 11:41 AM, Silvio Heinrich <span \
dir="ltr"><<a href="mailto:plassy@web.de">plassy@web.de</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> Am 29.07.2011 23:30, schrieb JL VT:<br>
<div class="im">> I don't know how fast Krita is in the other branches (I \
haven't tested)<br> > however I'd like to ask if there's a good date \
to start feeling really<br> > worried about speed?, I don't want 2.4 to be a \
single bit slower than<br> > 2.3, so I'd like to start hacking to try to find \
where our current<br> > bottlenecks are; but I don't know which parts deep in \
Krita to touch<br> > without stepping on other developer's toes, moreover, my \
fears may be<br> > unfounded, maybe we're just a couple weeks shy of a branch \
merge solving<br> > all these problems, but, again, I haven't kept up enough \
with our IRC<br> > backlogs and Krita branches to be sure.<br>
><br>
> Should I be worried?.<br>
><br>
> Is there an upcoming branch I should be testing to help with the speed<br>
> bottlenecks instead?.<br>
><br>
<br>
</div>As far as I know we have two big bottle necks.<br>
The first is the creation and transformation (rotation, scaling) of the<br>
brush masks. The last time I profiled krita it spent 20-30% (I can't<br>
remember exactly anymore) of the whole processing time while painting<br>
with this operations.<br></blockquote><div><br><br>Depends on which brush is used. \
Autobrush shows about 30% of the time in processing the mask, but it's not using \
100% cpu. I think there is another bottleneck that callgrind doesn't show. \
Painting with predefined brushes shows a big performance bottleneck in scaling the
brush (callgrind file: <br>
<a href="http://depot.tu-dortmund.de/get/syvg6">http://depot.tu-dortmund.de/get/syvg6</a>
) in the stroke benchmark. There is a single method
that takes most of the time, so that should be the first target when
trying to speed up things.<br> </div><blockquote class="gmail_quote" style="margin: \
0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> \
The second one is the huge memory consumption of krita. I think it would<br> be \
unlikely that the process of painting itself gets faster with a lower<br> memory \
consumption but the overall execution of krita.<br> If a lot of memory is used (and \
I'm talking about gigabytes) the OS<br> needs a lot more processing time to \
manage the memory what makes krita<br> slower too. And its not uncommon that you \
reach the memory limit of your<br> system when using krita. I often have 2-4GBs in \
use.<br></blockquote><div><br>Most of the memory consumption is used to speed up \
things e.g. all the projection are using a huge amount of memory but save processing \
power that would be needed to recalculate them. </div></div><br>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic