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) ...
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.
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
Navin, Is there a defect filed for the enhancement ? When was the check-in done ?
There was a bug about this and it was checked in almost a month back, I believe.
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.
Marking verified worksforme. A couple bugs fixed in recent times include bug 85029 and bug 104243.
Status: RESOLVED → VERIFIED
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.