<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"><<a href="mailto:lukast.dev@gmail.com">lukast.dev@gmail.com</a>></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>
> On Friday 23 October 2009, Dmitry Kazakov wrote:<br>
> > Well, i agree with you! =) If you say this code is rarely used, it won't<br>
> > help us boost performance =)<br>
> ><br>
> > PS:<br>
> > /me still thinks that using strings for internally used constants is a<br>
> > bad practice =)<br>
> > And /me doesn't think implicit sharing of QString will excuse it.<br>
> > But i wont argue about it this time =)<br>
><br>
> Indeed it doesn't, I just read the Qt code: it first compares the size,<br>
> then does a very optimized memory comparison. I would have thought it<br>
> would have done a comparison of the shared pointer, but no doubt the Qt<br>
> hackers know better.<br>
><br>
<br>
</div>I'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'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'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'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>