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

List:       kmail-devel
Subject:    Re: Displaying large message takes loooong
From:       Don Sanders <sanders () kde ! org>
Date:       2002-10-31 10:20:50
[Download RAW message or body]

On Wednesday 30 October 2002 23:47, Martin Koller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wednesday 30 October 2002 07:47, Don Sanders wrote:
> > On Tuesday 15 October 2002 22:32, Michael Brade wrote:
> > ...
> >
> > > This is really a big problem for my University, I'm responsible
> > > for the KDE installation and it is the reason people don't want
> > > me to install KMail as default mailer :-(
> >
> > I suggest finding or creating a bug entry and voting for it. I
> > can fix this but it will take some work so I would like to know
> > for for sure that it's important. I'll consider bugs with many
> > votes important and give priority to them.
>
> I thought you have already solved that problem (you submitted a
> qcstring patch a while ago).
> If Trolltech does not include it, it should be simple to create a
> new function which uses their code+ your patch.

I've been a Trolltech employee for awhile now, I've committed the 
change already, and it will almost certainly be included in Qt 3.1.

> So where is the problem?

Michael is talking about a completely different problem, that is 
delaying loading of attachments from an IMAP server until they are 
displayed. That will take some more work to fix.

> Also, there was no response to my following question:
> - -------
> But what I do not understand is:
> Why does kmail at all parse that message, when it eventually shows
> only the attachments as icons ?
> If you also could remove that, then the first problem would be less
> worse. - --------
>
> Can you comment on this, please?

Yes that's inefficient. FWIW the parsing code is extremely 
inefficient, I'm working on that but I'm focussed primarily on 
reducing excessive memory consumption rather than optimizing for 
speed, this just happened to be an exceptional case where parsing was 
slow even though memory use wasn't that bad.

Don.

_______________________________________________
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]