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

List:       kmail-devel
Subject:    Re: Displaying large message takes loooong
From:       Marc Mutz <mutz () kde ! org>
Date:       2002-10-11 18:26:51
[Download RAW message or body]

On Friday 11 October 2002 17:45, Martin Koller wrote:
<snip>
> is this a known issue, that if I select a message, which is about
> 850KB in size (it has 2 attachments, one with 639KB, one with 209KB),
> kmail processes for about 60 seconds before responding and
> displaying?

How many body parts does the message have? three? How big is the test 
part? What type are the other body parts? 

> (Is that what Don enhanced with his zero copy patch in make_it_cool
> ?)

No.

> #1  0x40f5ca5f in QString::remove () at eval.c:41
<snip>
> #6  0x0814ec07 in KMMessagePart::bodyDecoded (this=0x86974c0) at
> /usr/lib/qt3-gcc2.96/include/qcstring.h:240
<snip>

This BT is fscked up. bodyDecoded is _certainly_ not in Qt ;-)

Yes, this replace call is a serious performance killer. We should get 
rid of it again. This requires changes to the KMime::Codec's: They need 
to know whether they work on text or (binary) data. In the first case, 
they need to convert to/from CRLF canonical form, in the latter they 
shouldn't.

Hmm, I'll see what I can do for 3.1.0. Else it's stuff for 3.1.1.

Can you please file a bug for component "mime" and assign it to me? 
Thanks.

Marc

-- 
"You're hackers, aren't you," the barman said, eyeing us. No one said
a thing. The darkness of the Eurotunnel rolled by. Apparently we'd
given ourselves away by talking too enthusiastically about IPv6. He
looked around conspiratorially, lowered his voice. "Can you get me
some credit card numbers?"
      -- James J. King "What's the shortest way to hack a Linux box?"
         Telepolis 2001/08/11 (#9293)

[Attachment #3 (application/pgp-signature)]
_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail

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