[KDE-Devel] QString optimization using a Proxy class called QStringTemp

[Fred P.]

>On Thursday 22 of April 2004 00:28, Fred P. wrote:
>>For more information see:
>>http://kde-apps.org/content/show.php?content=12158&forumexplevel=2
>>
>>It should work on Qt2, Qt3 or higher, need small modification on QString
>>class:
>>
>>- QString(int buffer_length, bool dummy);
>>is currently private, you have to change it to public or protected.
>>
>>- You also have to put ~QString to be a virtual function.

>A bit strange requirement for something like QString. Why exactly, just 
>because of a printf() ?

This is an "intensive" test case scenario.

I want to test the SPEED of QString/QStringTemp  VS QString only.

To do this you perform the same operator+
operation MANY times on MANY different sizes
in a timed loop to know the difference.

The reasons why I do it 5000 times or more, is to see an "actual" 
difference.

In fact, if you save even 1% in speed overall for all String operator+
without having to recode anything wouldn't that be great?

===========

For actual KDE scenario, I saw someone OPTIMIZING IMAP on KDE-CVS
and I tought that my patch for VCL and MFC could be easily ported to Qt.

http://members.shaw.ca/dkite/apr92004.html#oKde-Base
http://members.shaw.ca/dkite/apr22004.html#oKde-Base

More precisely:

"
Optimizations
George Staikos committed a change to kdebase/kioslave/imap4

11% reduction in malloc()s for dimap sync
14% reduction in strlen()s
result: approximately 7% less cpu

Diffs: 1, 2, 3, 4, 5, 6

George Staikos committed a change to kdebase/kioslave/imap4

another 10.5% faster yet (almost entirely due to eliminating malloc()s)

This could go faster but it would not preserve behaviour exactly, so I will
not risk it at this point.  Someone who speaks IMAP must due the rest.

Diffs: 1, 2, 3

George Staikos committed a change to kdebase/kioslave/imap4

more imap optimizations.  gives ~10% speed boost or so by removing excessive
buffer object creation and resizes, along with other object creation

Diffs: 1, 2, 3, 4, 5, 6, 7, 8
"

A similar patch could be made for QCString or similar.


>>
>>===============
>>
>>Improve speed performance of QString
>>while keeping the syntax readable as is.
>>
>>e.g.
>>QStringTemp tmp( 4096 );
>>QString s = tmp + a + b + c + d;
>>
>>OR
>>
>>uint sz = a::length() + b::length() + c::length() + d::length();
>>QStringTemp tmp( sz );
>>QString s = tmp + a + b + c + d;
>>
>>Another way is to modify the
>>QString::operator+
>>to use QStringTemp implicitely.
>>
>>Performance increase from few ms to 4x faster depending on the buffer size
>>and the size of each string.
>>
>>See test cases screenshots
>>for various buffer size algorithms.

>Do you have any more real-world examples? Concatenating thousands of 6000 
>chars long strings is probably not a very common scenario, and in cases 
>where performance of this could matter there's IMHO not a big difference 
>between explicitly using QStringTemp and QString::operator+=.

There's a big difference, it's easier to read and people wouldn't even have 
to bother
if the algorithm is tweaked properly, so it can anticipate.

>>
>>The Qt version of this code may be released under the GPL/QPL, if needed.

>That's not sufficient for Qt actually, all code for Qt needs to have 
>copyright assigned to TrollTech (because of the commercial versions).

I will approach TrollTech when it will be needed. License issues can be 
resolved,
the thing is as long as the other version of this patch for others 
non-commercial
and commercial String libraries are kept LGPL, BSD or public domain.

IMHO, I don't think MFC would accept a GPL/QPL patch, neither does Borland.


>Also, that 400+k archive is not the best way how to distribute one 6k .h 
>file and 2k readme file. Distribute it either as your files + diff or just 
>a diff (something like diff -u -p -d -N -r dir.old dir.new > dir.patch).

I will try that, later. =)

Sincerely yours,
Fred.

>--
>Lubos Lunak
>KDE developer
>---------------------------------------------------------------------
>SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
>Drahobejlova 27  tel: +420 2 9654 2373
>190 00 Praha 9   fax: +420 2 9654 2374
>Czech Republic   http://www.suse.cz/
>_______________________________________________
>Kde-optimize mailing list
>Kde-optimize at kde.org
>https://mail.kde.org/mailman/listinfo/kde-optimize

_________________________________________________________________
MSN Premium helps eliminate e-mail viruses. Get 2 months FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines