[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:       "Roy J. Tellason" <rtellason () verizon ! net>
Date:       2007-05-18 17:28:24
Message-ID: 200705181328.24757.rtellason () verizon ! net
[Download RAW message or body]

On Thursday 17 May 2007 16:27, Ingo Klöcker wrote:
> > > > > Getting the text of a message to display can take forever.

It certainly seems to take significantly longer with this version than it did 
with earlier versions,  in spite of the fact that I'm now running on a 
slightly faster machine.

> > > > > 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.

Optimized for large message stores?  Then why the default behavior of 
compacting those folders (that I have *MANY* of) which only exist here for 
archival purposes?  And no way to disable this,  either globally or in any 
individual folders?  This consumes significant resources on this machine. And 
would probably be worse once I switch back to my setup where the messages are 
held on another machine and accessed by way of nfs...

> > > > 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.

It did,  here.  And if I was unfortunately holding down that key (having 
actually wanting to hit the shift key so I could use arrow keys to mark a 
number of messages) it would bring up a great many copies of the current 
message,  each of which had to be closed before I could go back to what I was 
doing.  I finally went into the configuration and removed <enter> from the 
setup to avoid _that_ waste of time.

> > > > 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.

If time available to deal with this stuff were infinite,  or if I were a coder 
to begin with,  I probably would.  But apparently just being a _user_ doesn't 
count...

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin
_______________________________________________
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]