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

List:       kdepim-users
Subject:    Re: [kdepim-users] Fwd: KMail + IMAP painfully slow
From:       Ingo =?utf-8?q?Kl=C3=B6cker?= <kloecker () kde ! org>
Date:       2007-05-17 20:27:55
Message-ID: 200705172227.57592 () erwin ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 17 May 2007 00:14, Ross Boylan wrote:
> On Wednesday 16 May 2007 14:18, Ingo Klöcker wrote:
> > On Wednesday 16 May 2007 21:30, Ross Boylan wrote:
> > > > > Moving messages takes many minutes, sometimes (even when it's
> > > > > not many messages).
> > > >
> > > > What happens during those many
> > > > minutes? Is KMail eating CPU like mad? Or does is just hang and
> > > > do nothing?
> > >
> > > KMail eats CPU like mad.  It does so in all the scenarios I
> > > described.  I noticed today that when I moved some messages to a
> > > folder the columns on the left for unread and total started
> > > updating after I move the messages in.  It appears that after the
> > > messages are moved in KMail scans the target folder; I'm guessing
> > > kmail builds up its indices.
> >
> > If the total column is visible then KMail updates it at least on
> > the first start to get an initial value. You might try whether
> > disabling the total column helps.
>
> disabling just Total, or Total and Unread?  Both are getting updated.

Unread is only updated if the folder is accessed. Total is initially 
updated for all folders, i.e. KMail scans all existing folders for 
getting the Total count. I don't know how often Total is updated in 
between because I don't use it.

> > > I've also noticed some strange behavior.  I had about 7000
> > > messages on a remote server.  After I moved them to the local
> > > server I opened the remote folder.  kmail showed the messages
> > > that were previously there in the upper right pane (this is with
> > > the default setup for panes--not sure what their official name
> > > is).  It then started reducing the counts shown on the left, and
> > > eliminating message lines shown in the upper right.
> > >
> > > I got bored waiting for this to finish and I switched to another
> > > box. This made the countdown process stop.  When I switched back
> > > to the now-empty box kmail said "no new mail" and left the
> > > display as it was, i.e., the left pane showed the  box had quite
> > > a few messages, and the upper riight pane also showed quite a few
> > > messages.  I was eventually able to force a reread (I think I
> > > switched to another box on the remote server and then back to the
> > > empty one).
> >
> > Sounds like an update problem.
>
> Do you mean update of the display, or something else?

Yes, update of the display.

> > > Since the information in the counts is available from a single
> > > call to the IMAP server I conclude that kmail is not getting the
> > > information that way, but is instead building its own indices.
> >
> > I'm not sure how we do get the count. It's quite possible that we
> > just count the number of messages marked as unread in our caches
> > instead of using the number given to us by the IMAP server so that
> > we can use the same code also for local folders (where we have no
> > other choice but to count ourselves).
>
> I thought some programs wrote information directly into the message
> for non-IMAP mail.  I think mutt may put some status info there. 
> Otherwise, if you use a different mail client you won't have access
> to which messages are "seen."

KMail's mail storage is not meant to be shared with other mail clients. 
KMail stores such extra information in special index files from which 
the information can be extracted magnitudes faster than from the stored 
messages.

> > > > Getting the text of a message to display can take forever.
> > > >
> > > > I disabled automatic checking, and this seemed to help some. 
> > > > The manual check remains slow, I guess because it insists on
> > > > visiting every folder.
> > > >
> > > > Am I doing something wrong?  Is my mailstore bigger than KMail
> > > > was designed for?  Or is KMail just not that good at IMAP?
>
> Sounds as if the root of the problem is that KMail is not so good at
> managing large messages stores, wherever they reside.  But if the
> messages are in, for example, traditional mbox format, probably
> accessing the messages causes a bottleneck before indexing/caching
> becomes an issue.

In fact, KMail is highly optimized for large message stores (i.e. for 
message counts in the tens thousand). Once KMail has indexed a folder 
accessing the folder should be rather quick. But, of course, opening a 
folder with 30000 messages will still be slower than opening a much 
smaller folder.


> > > Also, as I reported above with the folder I emptied, kmail
> > > sometimes seems to get confused when I interrupt a task by
> > > switching folders or mailboxes.
> >
> > We do have a few bottlenecks in updating the message list (i.e. the
> > upper right pane). This list is often redrawn after each change and
> > that's painfully slow if lots of changes happen. When you leave the
> > folder then redrawing is obviously no longer necessary. I guess
> > this explains some of the behavior you saw.
>
> Are you saying that each folder has an associated graphical view that
> gets updated even if it's not displayed?

No.

> In the problem I described 
> above, the target folder information was getting updated, but the
> message list that was showing was always that of the source.

But the source did also change, didn't it?


> > > P.S. about the quick search: I keep entering the search term and
> > > then hitting enter.  The enter brings up the currently selected
> > > message, I think.  You might consider making the enter key a
> > > no-op in the search bar.  I'm accustomed to enter meaning "do the
> > > search".  I guess that, since the search is incremental, that's
> > > redundant in this case.
> >
> > You might want to file a bug/wish at bugs.kde.org for this.
>
> Yes, that's a simple one.  Anything useful I can do about the more
> general performance/responsive issues I encountered?  I'm not even
> sure how many distinct issues they involve.

I guess it would be helpful to collect those issues in a structured way. 
Obviously, it's best if they only describe a single operation at a 
time. If you feel like it you are of course welcome to dig into the 
code.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

_______________________________________________
KDE PIM users mailing list
kdepim-users@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-users


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