Re: QCString construction

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 =3D 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, [email protected], [email protected]
> KDE/KOffice developer, Qt consultancy projects
> Klar=E4lvdalens Datakonsult AB, Platform-independent software solutions
> _______________________________________________
> Kde-optimize mailing list
> [email protected]
> https://mail.kde.org/mailman/listinfo/kde-optimize
>

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