Bug 37054 - kmail extremly blocking while pop3 mail retrieve
Summary: kmail extremly blocking while pop3 mail retrieve
Status: RESOLVED DUPLICATE of bug 41514
Alias: None
Product: kmail
Classification: Unclassified
Component: general (show other bugs)
Version: 1.3.8
Platform: Compiled Sources Linux
: NOR wishlist with 20 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-01-10 20:48 UTC by Joseph Wenninger
Modified: 2007-09-14 12:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Wenninger 2002-01-10 20:38:40 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           kmail
Version:           1.3.8 (using KDE 2.9.0 2 (CVS >= 20020104))
Severity:          normal
Installed from:    compiled sources
Compiler:          gcc version 2.95.3 20010315 (SuSE)
OS:                Linux (i686) release 2.4.10-4GB
OS/Compiler notes: 

Hi

I use kmail for my daily email but it has really problems with the performance.

My Setup:
Athlon 1.4 GHz
512 MB Ram
Fast Ultra 160 SCSI Harddrive
28800 Modem

While retrieving mail from my pop3 account and automatic filtering I'm unable to write an email because the whole application blocks approximatly for 1 second every two seconds.

The main window doesn't repaint regularily too while retrieving mail.
I don't know if it is related to my folder sizes but i have approximatly ten thousend mails per folder.

Kinde Regards
Joweph Wenninger

(Submitted via bugs.kde.org)
(Called from KBugReport dialog)
Comment 1 Ingo Kl 2002-01-12 12:55:08 UTC
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 10 January 2002 21:38 jowenn@kde.org wrote:
> Package: kmail
> Version: 1.3.8 (using KDE 2.9.0 2 (CVS >=3D 20020104))
> Severity: normal
> Installed from:    compiled sources
> Compiler:          gcc version 2.95.3 20010315 (SuSE)
> OS:                Linux (i686) release 2.4.10-4GB
> OS/Compiler notes:
>
> Hi
>
> I use kmail for my daily email but it has really problems with the
> performance.
>
> My Setup:
> Athlon 1.4 GHz
> 512 MB Ram
> Fast Ultra 160 SCSI Harddrive
> 28800 Modem
>
> While retrieving mail from my pop3 account and automatic filtering
> I'm unable to write an email because the whole application blocks
> approximatly for 1 second every two seconds.
>
> The main window doesn't repaint regularily too while retrieving
> mail. I don't know if it is related to my folder sizes but i have
> approximatly ten thousend mails per folder.

The problem is probably caused by the fact that the header list is=20
recreated every few seconds. And for 10.000 messages this takes some=20
time.

Possible workaround:
- - Select the outbox (or some other folder which only contains a few=20
messages) before manually checking for new messages.
Does this help?

Possible solutions:
- - Don't update the header list until the download of messages has=20
stopped. Of course we currently do update the header list every few=20
seconds to show the user directly in which folders new messages=20
arrived.
- - Make updating the header list faster.

Regards
Ingo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8QDItGnR+RTDgudgRAmMPAJ9Ds6i3fxGhIL0HskGQNBgXq4UxkACdHfEl
Iqn/aaPxMfgNjsxdAJWBE+4=3D
=3DyBvv
-----END PGP SIGNATURE-----
Comment 2 Michael H 2002-01-12 14:47:32 UTC
On Saturday 12 January 2002 13:55 Ingo Klöcker wrote:
>
> The problem is probably caused by the fact that the header list is
> recreated every few seconds. And for 10.000 messages this takes some
> time.
>
> Possible workaround:
> - Select the outbox (or some other folder which only contains a few
> messages) before manually checking for new messages.
> Does this help?

Judging from the problem description I assume the problem are actually the 
other folders and not the selected one.

Currently always the folders are opened and the whole index file is read when 
mails are appened. That could eventually be changed.

> Possible solutions:
> - Don't update the header list until the download of messages has
> stopped. Of course we currently do update the header list every few

Not really nice for non-blocking recieving and for people with smaller folders 
this problem doesn't appear.

> - Make updating the header list faster.

Probably not possible without getting again rid of the alternating colours.

We could also use threads for certain operations but for sure not for KDE3.

Regards
Michael Häckel
Comment 3 Joseph Wenninger 2002-01-12 16:48:25 UTC
Hi

> >
> > Possible workaround:
> > - Select the outbox (or some other folder which only contains a few
> > messages) before manually checking for new messages.
> > Does this help?
>
> Judging from the problem description I assume the problem are actually
> the other folders and not the selected one.
>
> Currently always the folders are opened and the whole index file is read
> when mails are appened. That could eventually be changed.
>

I thought that my problem could be caused by the filtering because some time 
ago I I looked into the filtering code to add a dialog which shows some kind 
of progress (the patch was rejected on this list) when applying filters 
manualy I noticed that even much smaller folders needed ages for filtering 
for each mail.

Reparsing the whole indices sounds reasonable. Can't they be cached in the 
ram when there is enough around ?


The kde mailinglists create a lot of traffic that are most of my large 
folders.


I was just wondering because back when I used outlook 2000 on win200 on my 
PII 350 it blocked less than kmail on my new computer.

Kind regards
Joseph Wenninger
Comment 4 Michael H 2002-01-12 17:50:17 UTC
On Saturday 12 January 2002 17:48 Joseph Wenninger wrote:
>
> I thought that my problem could be caused by the filtering because some

Filtering as such surely doesn't take very long.

> time ago I I looked into the filtering code to add a dialog which shows
> some kind of progress (the patch was rejected on this list) when applying
> filters manualy I noticed that even much smaller folders needed ages for
> filtering for each mail.
>
> Reparsing the whole indices sounds reasonable. Can't they be cached in the
> ram when there is enough around ?

I don't know how many mails and how much RAM you have but that might take a 
lot of RAM.
They are already cached until mail checking is over for folders that get new 
mail.

> The kde mailinglists create a lot of traffic that are most of my large
> folders.

Well I still don't what actually your problem is. What exactely is happening 
that is slow? Are that mails that arrive in the current folder or mails that 
arrive in other folders? Are you talking about interval mail cheking where 
only one mail every few minutes arrives or manual checking?

Regards
Michael Häckel
Comment 5 Jörg Rüppel 2003-08-27 15:12:59 UTC
My problem for sure is that KMail blocks while SpamAssasin is parsing incoming 
mail and blocking the whole of kmail. When every few minutes new 
to-be-filtered spammails arrive using kmail to read mail at the same time 
becomes a real pain. 
Comment 6 W. Blake Caldwell 2004-02-12 04:18:29 UTC
I had a similar problem... I have about 25 filters, each with about 2-4 conditions, and 1-2 actions.  When the filters were performed on the incoming mail, the whole GUI would lock up.  I found the same problem when i selected messages and applied my filters. It would lock up for 10-15-20 minutes or longer, even with only a few messages selected for filtering.

So the problem was with the filters - they were taking forever.

i messed around with it some more and found that it was the filters with regex's in them.  I removed them all so that i just did straight content matching - that did the trick.

my system had a horrible time with the regex's, which i was sad to see, since it's such a great feature.  FYI - i'm running a 2.4Ghz toshiba celeron laptop with 256MB ram -- my system wasn't the problem.

please lemme know if this is helpful

thanks in advance - and btw, i otherwise LOVE Kmail
- blake caldwell <blake AT pluginbox DOT com>
Comment 7 Helge Hielscher 2004-05-15 07:59:05 UTC
sounds like a dup of bug 41514
Comment 8 Stephan Kulow 2004-05-15 11:05:13 UTC
indeed

*** This bug has been marked as a duplicate of 41514 ***