From Bugzilla Helper: BuildID: 2002053012 If you do a message search on various criteria, the algorithm doesn't optimize or short circuit. Here's an example: Search for all messages from Alice containing "Bob". Watch as Mozilla looks for all messages from Alice and then all messages containing "Bob" and at the end does an intersection to return the results. Think to yourself, man it'd be 100x faster if it found Alice's messages and only body searched those. The mailer should delay body searching until all other criteria are done. So with an "or" it doesn't need to body search if another criteria already passed. With an "and" search it can short circuit away from a message if one of the fast criteria returns false. Reproducible: Always

*** Bug 167724 has been marked as a duplicate of this bug. ***

new

Just a note to say it still exists in Thunderbird 0.5. Searching for all emails from "bob" takes 10 seconds, while searching for all message sent from "bob" and which body contains "hello" takes 5 minutes.

*** Bug 155645 has been marked as a duplicate of this bug. ***

The mail search is so slow I try to avoid it if at all possible, partly because of lack of short-circuit logic. Just commenting that this is more important than it might seem. Yes I will vote for it but that has no meaning, as we all know by now.

Hi, I just "voted for this bug". This is very serious. Severity is now currently "enhancement", but frankly, for a mail product that is supposed to allow users to check exisiting mail contents quickly, this is rather critical. (Yes, it is not a bug that crashes the program, but is really shattering the expectation of its users.) I just did a similar experiment like the one mentioned in 155645 and figured the mailer is not using short-circuting the evaluation (I specified sender condition first and then "body contains" the second) before searching the bugzilla database and found this bug. So just like Aaron Lawrence I would like to comment that this is more important than it might seem. >Yes I will vote for it but that has no meaning, as we all >know by now. Oh, is it? Anyway I voted just a few minutes ago. Actually it was my first vote :-)

Perhaps identifying in this bug, the code responsible for search, would help prod another volunteer to post candidate patches? Message filters: Do they suffer same lack-of-short-circuiting (is it the same code, or just the UI forms look similar)? If so: update the Summary, from "Search should ..." to "Search and filters should ..."? Trying to determine why my mozilla (1.5) getMail is so slow. (Or the unsupported movemail -- the only server type I use -- is just dog-slow versus all other server types?) Some of my match-all filters have multiple "Body doesNotContain ..." clauses, and some of these exact clauses are repeated in more than one filter. So a separate opportunity exists (over and above the more important/basic short-circuiting feature) to cache the results of each clause in each filter, to speed-up later filters in which same clause reappears?

Yes but filters aren't likely to be a performance issue, because they only apply to a few messages at a time. Lets compare and contrast to Gmail: near-instant full text search of your entire mailbox. Is there any reason why Mozilla shouldn't aim to do the same? (Putting aside technical objections)

I think this is identical to bug #166502. One of them should be marked as a dup of the other.

Indeed - good spotting. And even better, there is a fix in bug 295088 which covers both filters and searches! *** This bug has been marked as a duplicate of 166502 ***