Search is 50x slower than Communicator

VERIFIED WORKSFORME

Status

SeaMonkey
MailNews: Message Display
VERIFIED WORKSFORME
17 years ago
10 years ago

People

(Reporter: Julien Pierre, Assigned: Navin Gupta)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
I have several large mail folders, with thousands of messages. I have measured
the time it takes to do a search based on one of the standard headers
("subject"). I tested this by migrating my mail database from Communicator to
Netscpae 6.2 and measuring the time it took to search the databases in both
programs :

In my main inbox folder, with about 5800 messages :
- with Communicator 4.78, 2 seconds (mail database on NTFS)
- with Netscape 6.2, 92 seconds (mail database on FAT, due to migration forced
to C: in installer)

The windows PC is a PII 450 with 384 MB of RAM, running Win2k server and UW SCSI.

I then proceeded to ftp my mail database to an OS/2 machine, running a Pentium
II 400 w/ 192 MB of RAM and IDE.

- with Communicator 4.61, 13 seconds (mail database on JFS)
- with Mozilla 0.9.5 for OS/2, over 400s (mail database on JFS. sorry, lost
exact count, it's over 6 minutes !!!...)
While the search was running in Netscape 6.2, there was less than 5% CPU
activity on the machine according to the Win2k task manager. The OS/2 Warpcenter
did not register any CPU activity at all with Mozilla, and a very low percentage
with Communicator. The disk LED was also barely hit throughout the very long
searches on either system. It seems that the browser is just idling during the
search. It may be because of the animated display during search, but I'm not
certain if that is the cause. Either way, it is a very important usability
issue. I'm able to do my manual searches a *LOT* faster than the automated ones
at the moment, just by doing "sorts" based on headers, and looking through them
on the screen. Unfortunately in many cases that's not good enough and I need the
automation.
I haven't even tried to enable "search all subfolders" and search on "body"
instead of headers, as it would probably take forever ...

This is a big usability issue for the mail program as far as I am concerned. I
have an even bigger mail database to search at home (more than half a gigabyte) ...
(Reporter)

Comment 1

17 years ago
FYI, I have tried with other smaller folders and the length of searches was
directly propertional to the number of messages in the folder - about 1/5th of
the time for a folder with 1000 messages.

Stephane, I think this is a must fix for the enterprise client release.  I'm not
sure how to bring more attention to this defect and who the right people are to
cc for e-client and/or performance issues.

(Assignee)

Comment 2

17 years ago
This issue has already been addressed on the trunk builds. I believe this was
done just before I landed "Quick Search" feature on trunk.  
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

17 years ago
Navin,

Is there a defect filed for the enhancement ? When was the check-in done ?
(Assignee)

Comment 4

17 years ago
There was a bug about this and it was checked in almost a month back, I believe. 
(Reporter)

Comment 5

17 years ago
Is there anything special to enable the quick search besides going to the
"search" menu as usual ?
I just tried on a 11/13 OS/2 trunk build but search didn't work - I couldn't
access the search dialog (fields were off the dialog) and then the browser just
aborted. I'm starting another build ne now and will check again on it tomorrow.

Comment 6

17 years ago
Marking verified worksforme.
A couple bugs fixed in recent times include bug 85029 and bug 104243.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

Updated

10 years ago
Component: MailNews: Search → MailNews: Message Display
QA Contact: laurel → search
You need to log in before you can comment on or make changes to this bug.