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:
perator+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.
The Qt version of this code may be released under the GPL/QPL, if needed.
Ratings & Comments
14 Comments
The version for current KDE 3.x CVS can be found here. http://kde-apps.org/content/show.php?content=12191 QStringTemp for Qt 2.2.3 had 14 comments up to date.
how do you apply this patch? i'm interested in using this.
You only need in the tarball ./qtools/qstringtemp.h In your KDE CVS dir change ./qtools/qstring.h You make: virtual ~QString() and you change in front of QString( int size, bool dummy ); private: --> protected: I had difficulty compiling qtools from KDE webcvs. Maybe someone can point me to a working out-of-the-box qtools KDE3 tarball ? It works perfectly with Qt 2.2.3 (Win32/Linux) provided in the tarball. Fred.
I got a working version for KDE 3.x =) I will post it tomorrow. ;-)
Optimizations are nice things but..why posting it here? I think your patch should go to a kde-devel mailing list, not to www.kde-apps.org
Why not post it here? These is a whole section devoted to improvements, not just gui. This improves speed and readability. In addition, it may spark others to come up with similar ideas.
I guess I have to sign up to all those mailling list. Also I needed a place where I could get minimal space for the tarball and output screenshots. It's also easier to get more attention here, than on the mailing list where your post get lost in the dust after a month. =(
No, you haven't, you can send your mail even without being subscribed, and you can send your patch there to be examined and discussed by all other KDE developers. This (kde-apps.org) is definitely a place for end-users who wants to find the most suitable KDE application for their needs, not a place for developer to discuss about improvements in the rough code. Ok, talking about UI improvements is a totally different thing, but in your case there's no UI at all. UI is used by user :) directly, code is managed by developers directly. Just my 2 cents
Ok, so let's close kde development mailing lists and let's all propose patches on kde-apps.org and discuss about them in comments. And let's see what happens.
Stop it. This guy has produced some excellent work. I think this is far more worthy of being here than the miriad of service .desktop files that are polluting kde-apps at the moment. I agree it is not really the correct place, but that doesn't excuse your behavior. It's just rude. And to the author, an excellent class, I will probably try to build on the concepts and make such a class for my apps. I hope it gets into Qt. One thing that occured to me while reading the description, is that this appears to be a good place for the compiler to try an make the optimisation of operator+ to operator+= itself. I wonder why it isn't done?
to the kde-optimize mailing list.....
Basically, the algorithm is a "Temporary String Proxy Design Pattern" http://www.google.com/search?q=design+pattern+proxy http://www.dofactory.com/patterns/PatternProxy.aspx http://www.javaworld.com/javaworld/jw-02-2002/jw-0222-designpatterns.html? http://www.openloop.com/softwareEngineering/patterns/designPattern/dPattern_Proxy.htm The idea is that the QStringTemp proxy has the same behavior than QString. The difference is that we "know" that it's a QStringTemp not a QString; therefore, we can leverage this opportunity to optimize. In other words, we are doing this: inline QStringTemp& operator+( T ) { QString::operator+=( T ); return *this; } So, instead of being tedious and write by hand: uint sz = a::length() + b::length() + c::length() + d::length(); QString tmp( (int)sz, true ); tmp += a; tmp += b; tmp += c; tmp += d; QString s = tmp; We simply write: uint sz = a::length() + b::length() + c::length() + d::length(); QStringTemp tmp( (int)sz, true ); QString s = tmp + a + b + c + d; which WAY MORE NATURAL! The thing is that, if QString::operator+( T ) always returned a QStringTemp and would always make a good estimate, see in the screenshot the section: "WITHOUT KNOWING QStringTemp buffer size in advance" Then you would simply have to recompile KDE and get the improvement all over the place! Needs a bit of tweaking around: #ifndef QStringTempSize #ifndef QStringTempShift #define QStringTempShift 3 #endif #define QStringTempSize( sz ) ( ((sz) + (sz) >> (QStringTempShift)) | 16 ) //#define QStringTempSize( sz ) ( ((sz) + (sz) >> 3) | 16 ) #endif Needs more benchmarking on various String concatenation scenarios. In the meanwhile, Enjoy! Long life to KDE! =)
Isn't this similar to following? QString result; QTextOStream(&result) << "pi = " << 3.14; The only diff. I can see is, that << is used instead of + and I can't find a constructor to set the initial stringsize of QStrings. http://doc.trolltech.com/3.3/qstring.html
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. http://doc.trolltech.com/3.2/qtextostream.html "QTextOStream class is a convenience class for output streams, providing a shorthand for creating simple output QTextStreams without having to pass a mode argument to the constructor." Where QStringTemp is just a proxy QString, which is used as a QString. It does NOT have to be an output stream.