QCString construction

[George Staikos]

Nice catch! :-)  Sounds familiar too.... like kio_imap.

On 9-Feb-07, at 7:43 PM, David Faure wrote:

> 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
> _______________________________________________
> Kde-optimize mailing list
> Kde-optimize at kde.org
> https://mail.kde.org/mailman/listinfo/kde-optimize
>

--
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/