[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Krita useable for Blender movies
From:       Sven Langkamp <sven.langkamp () gmail ! com>
Date:       2009-10-23 13:05:35
Message-ID: 478b087a0910230605h51a50bd4g9619d969b796691f () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Fri, Oct 23, 2009 at 2:59 PM, LukasT.dev@gmail.com
<lukast.dev@gmail.com>wrote:

> On Friday 23 October 2009 14:49:07 Boudewijn Rempt wrote:
> > On Friday 23 October 2009, Dmitry Kazakov wrote:
> > > Well, i agree with you! =) If you say this code is rarely used, it
> won't
> > > help us boost performance =)
> > >
> > > PS:
> > > /me still thinks that using strings for internally used constants is a
> > > bad practice =)
> > > And /me doesn't think implicit sharing of QString will excuse it.
> > > But i wont argue about it this time =)
> >
> > Indeed it doesn't, I just read the Qt code: it first compares the size,
> >  then does a very optimized memory comparison. I would have thought it
> >  would have done a comparison of the shared pointer, but no doubt the Qt
> >  hackers know better.
> >
>
> I'm student of image processing and we are taught that Strings, no matter
> how
> they are implemented, are in the end expensive in image processing. I never
> seen them in code which aims to be fast (OpenGL, OpenCV,...).
>
> But I don't say we should rewrite Krita and throw away QString, I just
> would
> not use them for comparison in loops etc. And the loops can be hidden
> pretty
> much, you can't say that this or that code will not be in a loop in the
> end.
> The reason? Because of complexity of Krita and image processing in general.
>
>
It's not like we are doing a string compare on every pixel. At the moment
string operations take only a small fraction of the whole processing.
What I learned was to make the common case fast. First we should concentrate
on the big performance problem and when strings make a bigger impact in the
end we can still optimize that.

[Attachment #5 (text/html)]

<div class="gmail_quote">On Fri, Oct 23, 2009 at 2:59 PM, <a \
href="mailto:LukasT.dev@gmail.com">LukasT.dev@gmail.com</a> <span dir="ltr">&lt;<a \
href="mailto:lukast.dev@gmail.com">lukast.dev@gmail.com</a>&gt;</span> wrote:<br> \
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Friday 23 October \
2009 14:49:07 Boudewijn Rempt wrote:<br> &gt; On Friday 23 October 2009, Dmitry \
Kazakov wrote:<br> &gt; &gt; Well, i agree with you! =) If you say this code is \
rarely used, it won&#39;t<br> &gt; &gt; help us boost performance =)<br>
&gt; &gt;<br>
&gt; &gt; PS:<br>
&gt; &gt; /me still thinks that using strings for internally used constants is a<br>
&gt; &gt; bad practice =)<br>
&gt; &gt; And /me doesn&#39;t think implicit sharing of QString will excuse it.<br>
&gt; &gt; But i wont argue about it this time =)<br>
&gt;<br>
&gt; Indeed it doesn&#39;t, I just read the Qt code: it first compares the size,<br>
&gt;  then does a very optimized memory comparison. I would have thought it<br>
&gt;  would have done a comparison of the shared pointer, but no doubt the Qt<br>
&gt;  hackers know better.<br>
&gt;<br>
<br>
</div>I&#39;m student of image processing and we are taught that Strings, no matter \
how<br> they are implemented, are in the end expensive in image processing. I \
never<br> seen them in code which aims to be fast (OpenGL, OpenCV,...).<br>
<br>
But I don&#39;t say we should rewrite Krita and throw away QString, I just would<br>
not use them for comparison in loops etc. And the loops can be hidden pretty<br>
much, you can&#39;t say that this or that code will not be in a loop in the end.<br>
The reason? Because of complexity of Krita and image processing in general.<br>
<div><br></div></blockquote></div><br>It&#39;s not like we are doing a string compare \
on every pixel. At the moment string operations take only a small fraction of the \
whole processing.<br>What I learned was to make the common case fast. First we should \
concentrate on the big performance problem and when strings make a bigger impact in \
the end we can still optimize that.<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]