inefficient QString coding practice

[Roberto Alsina]

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday 14 March 2004 16:17, Dominique Devriese wrote:
>> Adriaan de Groot writes:
>> > The original claim by Juergen was that bleh == "foo" incurs a
>> > considerable malloc / free and whatnot overhead and that it should
>> > be kept in mind. As long as there's no numbers attached, neither
>> > "doesn't really matter performance-wise" or "is important" can be
>> > evaluated.
>>
>> I think we can be pretty sure that a low, constant number of extra
>> instructions, and a low, constant number of extra malloc/free's
>> multiplied by a very low, and also constant number of occurences of
>> this practice won't matter much in the bigger image.
>
> Numbers, man, numbers. Without numbers, your vague emoting of "very low,
> and
> also constant" is just as meaningless as my "oodles". FWIW, there seem to
> be
> 351 occurrences in KMail, and some 1500 in all of kdepim. Since the
> relevance
> of each can only be judged in context (is it in a loop? more important)
> these
> numbers by themselves don't mean much either.
>
> So to sum up this thread: there are certainly cases where == "" is a bad
> thing
> due to the additional overhead, and people who genuinely care about
> performance should keep an eye out for them. The average developer
> probably
> _shouldn't_ worry about them unless string encoding or efficienct is
> particularly important in her or his code. Patches related to the use of
> ==
> "" should be welcomed.

Well, if anyone has ever run a profiled kmail, he would have noticed.

I don´t think it has been noticed. Ergo, I don´t think it´s noticeable ;-)

Of course someone should run a profiled kmail looking specifically for
this, just to be sure.

-- 
 ("\''/").__..-''"`-. .         Roberto Alsina
 `9_ 9  )   `-. (    ).`-._.`)  ralsina at kde.org
 (_Y_.)' ._   ) `._`.  " -.-'   KDE Developer (MFCH)
  _..`-'_..-_/ /-'_.'
(l)-'' ((i).' ((!.'             Buenos Aires - Argentina
Imminentizing the eschaton since 1971.