After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 212064 - Getting new messages using POP3 can be slow if mail kept on server
Getting new messages using POP3 can be slow if mail kept on server
Status: RESOLVED NOTABUG
Product: evolution
Classification: Applications
Component: Mailer
pre-1.5 (obsolete)
Other All
: Normal enhancement
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[POP]
Depends on:
Blocks:
 
 
Reported: 2001-10-09 00:49 UTC by Cyrus Hall
Modified: 2005-11-15 02:22 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Cyrus Hall 2001-10-09 00:49:02 UTC
Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem:
Every since Evolution 0.13, the mail client has been very slow downloading
messages from the server if the server has a large number of messages.  For
those of us that keep 5500 messages on the server it makes any newer
version than 0.12 unusable.

Steps to reproduce the problem:
1. Create 5000 messages (hell, 200 is enough)
2. Try to check mail
3. Wait for 30 minutes till done

Actual Results:
Mail is eventually received, but only after much frustration.

How often does this happen? 
Everytime.

Additional Information:
What going on is evolution seems to want to scan the head of every message
everytime it gets new mail.  For 5000 messages this is an unacceptable
cost.  The offending code is the pop3_generate_uids() in
camel/providers/pop3/camel-pop3-folder.c, invoked from pop3_refresh_info().
Comment 1 Jeffrey Stedfast 2001-10-09 04:05:28 UTC
the only reason that it downloading the headers is because other than
that, there is no way for evolution to decide that it has already
downloaded the message.

If your pop server supported UIDL, then it would be much faster.
Unfortunately, without UIDL we have no choice but to download all the
headers to md5 sum them and compare against previously downloaded
header md5 sums.