Closed
Bug 85029
Opened 23 years ago
Closed 23 years ago
searching large mail folders is incredibly slow
Categories
(SeaMonkey :: MailNews: Message Display, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
Future
People
(Reporter: webmaster, Assigned: naving)
References
Details
(Keywords: perf)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.18 i686; en-US; rv:0.9.1) Gecko/20010607
BuildID: 2001060713
Searching mail folders with lots of messages is so slow that it's unusable.
With Mozilla 0.9, searching a mail folder with 15000 messages (on my local HD)
for a keyword in the subject (not even body!) takes 5 minutes and 10 seconds.
With Netscape Communicator 4.77, the exact same search in the same folder took 4
seconds. The test was run on a reasonably fast machine, Athlon 1GHz, 256MB RAM,
no other apps running.
A strange thing is: during its slow search, Mozilla did not use lots of CPU
time. While Mozilla was searching, its CPU usage was between 3 and 10%, and the
CPU was around 90% idle. Disc access speed isn't the bottleneck either since the
mail file resides on a local, very fast HD.
Reproducible: Always
Steps to Reproduce:
1.Get a large email folder with several thousand messages (e.g. from mailing list).
2.Search -> Search Mail/News messages
3.Search for a keyword in the subject and see how slow it is.
Actual Results: It took ages until the search completed
Expected Results: Search performance should be at least similar to Netscape
4.77. Twice as slow or three times as slow would be ok for me, but 60 times as
slow (the current state) isn't acceptable.
Comment 2•23 years ago
|
||
moving to the future milestone.
cc seth because we were talking about this... I find search is really slow IMAP
or POP on an account-wide basis compared to 4.x. There is also a bug
specifically reported about POP (bug 88449)... don't know if we want to combine
into a general search performance bug.
I don't think 94602 has anything to do with this. Search is generally slow,
IMAP or POP.
Perhaps bug 98141 (currently unconfirmed) might have some relation to this bug?
Assignee | ||
Comment 7•23 years ago
|
||
Please try a newer build. The search should be faster now because a related was
fixed recently - bug 94602. laurel, I think he is complaining about local, should
be dup of 88449
Comment 9•23 years ago
|
||
Still very slow. Searching 2000 messages in my Inbox on Subject (POP3 account)
on 600MHz PC running Win98se takes 3 minutes. During those 3 minutes there's
very little disk activity and the CPU is about 96% idle!
This http://bugzilla.mozilla.org/show_bug.cgi?id=94602 bug was fixed by removing
bogus 1/2 second waits - perhaps there are more of these lying around.
Running:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20010913
Assignee | ||
Comment 10•23 years ago
|
||
This should have speeded up by more than 500 times. bienvenu checked in that
fix. I am inclined to mark this fixed.
Keywords: nsbeta1
Comment 11•23 years ago
|
||
well it took me like 10 seconds to find one message out of only 300
seems too slow for me
Assignee | ||
Comment 12•23 years ago
|
||
what build are you using?
Comment 13•23 years ago
|
||
Wow. Has something been commited in the past week to fix this? I just upgraded
to 2001011805 and now the searches are done as soon as i click the button
I was using a build dated october 12 or so in my posting yesterday
Assignee | ||
Comment 14•23 years ago
|
||
marking fixed, can't find the bug that actually fixed this, but I know because
we are scanning 500 headers for each time slice.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I thought bienvenu fixed this?
Comment 16•23 years ago
|
||
I think naving was referring to bug 104243
Assignee | ||
Comment 17•23 years ago
|
||
yes, thanks laurel.
Comment 18•23 years ago
|
||
OK for me using nov19 commerical trunk build: win98, linux rh6.2 and mac OS X
Updated•20 years ago
|
Product: Browser → Seamonkey
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.
Description
•