Re: QCString construction

This leads me to 3 patches.

One for kmail, I wrote a utility function for creating a
QCString from char*+size, and used that
when creating a QCString from a DwString where it matters
(i.e. where I found pretty large strings
to be used when attaching large files).
Can a kmail developer review the change to
KMMessage::asString() and asSendableString(), too?
It avoids a asString() (Assemble) and a fromString (Parse),
but I hope it's doing the right thing.

One for Qt itself: why does QCString use the slow way when
duplicating QCStrings?
(I know that QCString tmp( s1 ); is shallow copy, but the
next line calls operator+= which calls detach)
Unless someone spots a flaw in this patch I'll be posting it
to TT (and I'm testing my local kde with it
starting from tomorrow ;)

And one for mimelib, not really related to QCString: am I
right that memcpy is faster than for (i=0; i < pos1; ++i)
*to++ = *from++; ?
At least in gdb it seems faster, but I didn't benchmark it.
Hopefully memcpy is done by a single CPU instruction or
something, right?

Finally, I wish we could avoid the data copying just to
null-terminate it in KMMessagePart::body(), but I'm not sure
how...

-- 
David Faure, faurekde.org, dfaureklaralvdalens-datakonsult.se
KDE/KOffice developer, Qt consultancy projects
Klarälvdalens Datakonsult AB, Platform-independent software
solutions

_______________________________________________
Kde-optimize mailing list
Kde-optimizekde.org
ht
tps://mail.kde.org/mailman/listinfo/kde-optimize

On 9-Feb-07, at 8:16 PM, David Faure wrote:

> This leads me to 3 patches.
>
> One for kmail, I wrote a utility function for creating
a QCString  
> from char*+size, and used that
> when creating a QCString from a DwString where it
matters (i.e.  
> where I found pretty large strings
> to be used when attaching large files).
> Can a kmail developer review the change to
KMMessage::asString()  
> and asSendableString(), too?
> It avoids a asString() (Assemble) and a fromString
(Parse), but I  
> hope it's doing the right thing.

   IIRC there are lots more cases of mimelib doing things
like this  
including in the internals.

> And one for mimelib, not really related to QCString: am
I right  
> that memcpy is faster than for (i=0; i < pos1; ++i)
*to++ = *from++; ?
> At least in gdb it seems faster, but I didn't benchmark
it.  
> Hopefully memcpy is done by a single CPU instruction or
something,  
> right?

    memcpy() is often implemented with vector operations so
it should  
definitely be faster in many cases.

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



_______________________________________________
Kde-optimize mailing list
Kde-optimizekde.org
ht
tps://mail.kde.org/mailman/listinfo/kde-optimize

On Saturday 10 February 2007 02:16, David Faure wrote:
>
> One for Qt itself: why does QCString use the slow way
when duplicating
> QCStrings? (I know that QCString tmp( s1 ); is shallow
copy, but the next
> line calls operator+= which calls detach) Unless
someone spots a flaw in
> this patch I'll be posting it to TT (and I'm testing my
local kde with it
> starting from tomorrow ;)

I think it is because all these will require detach, so a
new string has to be
allocated anyway.
But will it be large enough to avoid an extra copy when
appending?
The tmp constructors could use a hint that they will grow.
That could be done in the append anyway...

Have you benchmarked that your Qt patch really is faster?

/RogerL
_______________________________________________
Kde-optimize mailing list
Kde-optimizekde.org
ht
tps://mail.kde.org/mailman/listinfo/kde-optimize

On Saturday 10 February 2007 02:16, David Faure wrote:
> This leads me to 3 patches.
>
> One for kmail, I wrote a utility function for creating
a QCString
> from char*+size, and used that when creating a QCString
from a
> DwString where it matters (i.e. where I found pretty
large strings to
> be used when attaching large files).

The related changes look good. I'm just wondering why you
didn't add
  QCString CString( const DwString & str )
instead of (or additionally to)
  QCString CString( const char* str, size_t strLen )
?

This would allow us to do
-  return asDwString().c_str();
+  return KMail::Util::CString( asDwString() );
instead of
-  return asDwString().c_str();
+  const DwString& asString = asDwString();
+  return KMail::Util::CString( asString.c_str(),
asString.length() );

> Can a kmail developer review the change to
KMMessage::asString() and
> asSendableString(), too? It avoids a asString()
(Assemble) and a
> fromString (Parse), but I hope it's doing the right
thing.

I am very uneasy about those changes because completely
different things 
happen when you copy a message and when you create a message
from a 
string. If we had unit tests... But as it stands I'm against
those 
changes.

Regards,
Ingo

_______________________________________________
Kde-optimize mailing list
Kde-optimizekde.org
ht
tps://mail.kde.org/mailman/listinfo/kde-optimize