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 593020 - Do not check Bcc in "Sender or Recipients" condition
Do not check Bcc in "Sender or Recipients" condition
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.32.x (obsolete)
Other FreeBSD
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[vfolders]
Depends on:
Blocks:
 
 
Reported: 2009-08-25 14:42 UTC by Wayne Sierke
Modified: 2011-01-10 18:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Wayne Sierke 2009-08-25 14:42:59 UTC
While investigating sluggish performance with vfolders I noticed a severe change in vfolder refresh time when switching between a condition set which included a "Sender or Recipients" condition and a combination of separate "Sender" and "Recipients" conditions.

e.g. given a vfolder configured as:

Include: <All related>
Conditions: <Sender or Recipients> <contains> <domain.name>
Folder Sources: <Specific folders>
imap:<account>/INBOX       (4900 Messages)
imap:<account>/INBOX:Sent  (1730 Messages)

A refresh of this vfolder such as that which occurs when selecting it consistently takes around 7 seconds. Modifying to:

Conditions: <Sender> <contains> <domain.name>

or

Conditions: <Recipients> <contains> <domain.name>

or even:

Find items: <If any conditions are met>
Conditions: <Sender> <contains> <domain.name>
Conditions: <Recipients> <contains> <domain.name>

I see a refresh time of well under one second.

Similar results were observed on three separate vfolders, including one where two separate sets of "Sender or Recipients" conditions were each broken up into separate "Sender" and "Recipients" conditions.

A separate test conducted on a larger imap-based folder seemingly indicated that using "Sender" or "Recipients" alone used the locally cached message headers whereas using "Sender or Recipients" caused the retrieval of tens of thousands of messages from the server. Whether that was headers only or full messages was not apparent. (In fact this test was canceled and abandoned before it was able to complete, after some ten or 15 minutes).
Comment 1 Chenthill P 2009-08-27 12:54:58 UTC
Did you see this behavior in only this specific version or in evolution 2.24.x also ? Am ask this just to narrow down..
Comment 2 Wayne Sierke 2010-12-01 07:13:36 UTC
I still see this in 2.30.3.

Sorry for belated response.
Comment 3 Wayne Sierke 2010-12-05 07:11:33 UTC
I still see this in 2.32.1
Comment 4 Milan Crha 2011-01-10 13:39:59 UTC
The "Sender" rule is checking a "From" header
The "Recipients" rule is checking "To" and "Cc" headers
The "Sender or Recipients" rule is checking "From", "To", "Cc" and "Bcc" headers

Because the "Bcc" is not cached (stored in the summary), then it requires to open each message, which might mean to download it from a server. Maybe the "Bcc" header can be removed from the "Sender or Recipients" search rules (both for search folders and quick searches).
Comment 5 Matthew Barnes 2011-01-10 15:35:36 UTC
"Sender or Recipients" was supposed to be the union of headers from "Sender" and "Recipients", so if "Recipients" isn't checking "Bcc" then I think it's fine to drop it.
Comment 6 Milan Crha 2011-01-10 16:53:02 UTC
OK, thanks, so I changed this in evolution master. The patch can be backported, but due to no duplicates in more than a year I chose to commit to master only.

Created commit 06ba028 in evo master (2.91.6+)
Comment 7 Matthew Barnes 2011-01-10 18:04:23 UTC
That's fine, I'm not sure a 2.32.2 release is all that likely at this point.