Closed Bug 154867 Opened 22 years ago Closed 19 years ago

Search should short-circuit optimize

Categories

(SeaMonkey :: MailNews: Message Display, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 166502

People

(Reporter: mozilla, Unassigned)

References

Details

(Keywords: perf)

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Keywords: perf
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 155645 has been marked as a duplicate of this bug. ***
Blocks: 88449
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 :-)

Product: Browser → Seamonkey
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?
Assignee: sspitzer → mail
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 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.