QCString construction

David Faure dfaure at klaralvdalens-datakonsult.se
Sat Feb 10 01:43:30 CET 2007


I was debugging today the memory consumption by kmail (qt3) when sending signed emails with large attachments.
Among other things, I noticed many QCString(const char*) constructions in kmail, like:
QCString KMMessage::asString() const {
   return asDwString().c_str();
}
and
messagecomposer.cpp: mEncodedBody = dwPart->AsString().c_str();

This copies the data of course (as expected), but it has to do a qstrlen first, which takes
quite some time. In fact a lot of time, as proven below. Given that asDwString/AsString
returns a DwString which has a length method (returning a member variable), we can easily
avoid that penalty, at the expense of uglier code when constructing the QCString.

Here's a benchmark I wrote which proves how much we can gain (and it also proves
that the resulting qcstring is correct ;)

Results on amd64 with -g3 and no optimization:
QCString(char*) took 1582 milliseconds
QCString(n)+memcpy took 134 milliseconds
QCString()+setRawData took 31 milliseconds

Results on i686 with -O2:
QCString(char*) took 2558 milliseconds
QCString(n)+memcpy took 161 milliseconds
QCString()+setRawData took 35 milliseconds

Of course setRawData isn't always an option (like in asString() above),
but QCString(n)+memcpy looks like a pretty interesting improvement already.

JFYI.

-- 
David Faure, faure at kde.org, dfaure at klaralvdalens-datakonsult.se
KDE/KOffice developer, Qt consultancy projects
Klarälvdalens Datakonsult AB, Platform-independent software solutions


More information about the Kde-optimize mailing list