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

List:       kde-optimize
Subject:    Re: QCString construction
From:       David Faure <faure () kde ! org>
Date:       2007-02-10 22:59:48
Message-ID: 200702102359.49205.faure () kde ! org
[Download RAW message or body]

On Saturday 10 February 2007, Roger Larsson wrote:
> On Saturday 10 February 2007 01:43, 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();
> 
> The fastest string copy is not doing it at all...
I know that. And I'm considering making more use of DwString in the affected kmail code,
to avoid going via QCString.

> Why is code like this necessary? 
Because of the use of mimelib in kmail.

> Why returning a low level c_str? 
That's what I fixed.

> If it is why does it have to be in a hot path?
What do you want me to say? kmail mixes two string classes because of the use of mimelib.

> I have been guilty of optimizing code that is rarely used resulting in
Rarely used?? I'm only looking at the places where I found kmail to spend a lot
of time while sending large emails. I know all about the dangers of premature
or misguided optimization, this is really about making the bottlenecks faster, not just
any string copying I found.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
_______________________________________________
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]