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

List:       kde-optimize
Subject:    QCString construction
From:       David Faure <dfaure () klaralvdalens-datakonsult ! se>
Date:       2007-02-10 0:43:30
Message-ID: 200702100143.43577.dfaure () klaralvdalens-datakonsult ! se
[Download RAW message or body]

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@kde.org, dfaure@klaralvdalens-datakonsult.se
KDE/KOffice developer, Qt consultancy projects
Klarälvdalens Datakonsult AB, Platform-independent software solutions
_______________________________________________
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]