104243 - Local Search needs to do more than one header per time slice

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[David :Bienvenu]

For each time slice, local search only looks at one header. It should look at 10
or a 100 or more. That will speed up local search a lot, and will make quick
search actually feasible.

Comment 1

[Navin Gupta]

ya, I have the quick search going, and I found it real slow. This should help.

Comment 2

[David :Bienvenu]

Attachment: proposed fix

Comment 3

[David :Bienvenu]

Can I get some reviews? Also, Navin, you could apply the patch and see if helps
the performance problem you're seeing. The 100 number I'm using is somewhat
arbitrary. We can try tuning it as well.

Comment 4

[David :Bienvenu]

Attachment: wrong diff - this is the right one

Comment 5

[David :Bienvenu]

Comment on attachment 53157 [details] [diff] [review]
proposed fix

while an excellent patch, this is for an old bug :-)

Comment 6

[(not reading, please use [e-mail] instead)]

Comment on attachment 53162 [details] [diff] [review]
wrong diff - this is the right one

sr=sspitzer

Comment 7

[Navin Gupta]

sure, r=naving. 

Comment 8

[Navin Gupta]

It is still not that fast. For an inbox (imap, won't matter because 
offlineSearch) it takes 10-15 secs to search ~4300 messages, that yields
~140 matches.

Comment 9

[David :Bienvenu]

is it faster than yesterday? did you try increasing the 100 to something like
500 or 1000?

Comment 10

[Navin Gupta]

Yes, it is definitely faster than yesterday. But what is the optimal size. 
> = faster, 500 > 100 > 1. I haven't tried 1000 but I guess it will be faster
than 500. I think we should put this const at 1000, assuming that an average 
user has 1000(s) of messages in inbox. 500 is also decent.

Comment 11

[David :Bienvenu]

if you want to test the improvement this patch makes, you need to do a search
without any hits. Otherwise, you're just measuring the other stuff like
inserting into the view and repainting all the time. Ultimately, of course, you
have to measure and fix that stuff. We don't want to make the constant too big,
because we'll starve the UI. But I wouldn't be surprised if 1000 was OK. I'll
check it in as 500 and you can tune it later.

Comment 12

[David :Bienvenu]

fix checked in.

Comment 13

[laurel]

OK using nov 19 commerical trunk build: win98, linux rh6.2 and mac OS X. 
Large local folders now complete a search lickety-split.

Comment 14

[Miloslaw Smyk]

I think that 500 headers per time slice may be to many if email is being
searched in "body contains" mode. So, bug #155800 is probably caused by the fix
here.