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

List:       kde-optimize
Subject:    RE: [KDE-Devel] QString optimization using a Proxy class called
From:       "Fred P." <fprog26 () hotmail ! com>
Date:       2004-04-23 22:46:07
Message-ID: BAY14-F5tyVJdlybM7z000079a5 () hotmail ! com
[Download RAW message or body]

> 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@suse.cz , l.lunak@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@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


_______________________________________________
Kde-optimize mailing list
Kde-optimize@kde.org
https://mail.kde.org/mailman/listinfo/kde-optimize


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