436960 - selecting saved search with a lot of results can be slow

Status: RESOLVED FIXED

(MailNews Core :: Backend, defect)

Description

[David :Bienvenu]

rkent pointed this out over IRC. If you select a saved search over a single folder, even though the hits are cached, it can take a while to open the folder, even before the search is executed. I tried clicking on a saved search over a single folder with 20K hits, and it did take a few seconds. Breaking into the debugger, I saw that we were painting the scroll bar for every message added. I'll attach a simple patch that should help.

Comment 1

[David :Bienvenu]

Attachment: proposed fix

doing batching on the tree should help a lot here.

Comment 2

[David :Bienvenu]

Attachment: might as well do it for cross-folder saved searches as well

might as well do the same thing for cross-folder saved searches.

Comment 3

[Kent James (:rkent)]

I've applied this patch in my standard working environment. (Release build of TB trunk, running on Windows XP on a 1200 MHz processor. I used a version from CVS of 2008-05-23. Also applied are my current patches for bug 414179 and bug 428427).

I have a test case with a saved search, Subject Doesntcontain "test", which generates 8050 hits on a local Inbox folder with 8228 total messages, and size 597MB.

Before the patch, it was taking approximately 4-5 seconds to open saved searches. To do this test, I alternately select a folder with just a few messages, then select the saved search folder. During this 4-5 seconds, the UI was unresponsive.

After the patch, the same open searches take less time. For a quicksearch folder, it takes about 2 seconds to open. There are two distinct refreshes of the message pane. In the first, the top message is displayed. In the second, the bottom message is displayed. Each refresh takes about one second.

For a XF search of the same folder, the total opening takes about 1 second, and there is only a single refresh. So the XF view is clearly quicker to open than the Quicksearch version. (For those of you unfamiliar with the details, when you select the default "search subfolders" in a search screen, you get the XF view. If you unselect, you get the quicksearch view.)

But the patch clearly improved performance by a factor of 2 to 4.

Comment 4

[[e-mail]]

Comment on attachment 323472 [details] [diff] [review]
might as well do it for cross-folder saved searches as well

>       }
>-    }
>+      if (mTree)
>+        mTree->EndUpdateBatch();
>+   }
>   }
Whitespace whoopsie ;-)

Comment 5

[David :Bienvenu]

(In reply to comment #4)
> (From update of attachment 323472 [details] [diff] [review])
> >       }
> >-    }
> >+      if (mTree)
> >+        mTree->EndUpdateBatch();
> >+   }
> >   }
> Whitespace whoopsie ;-)
> 

Yes, it looks like a space got removed before that last } - I've fixed that locally, and now the diff looks a lot less confused.

Comment 6

[Mark Banner (:standard8)]

Comment on attachment 323472 [details] [diff] [review]
might as well do it for cross-folder saved searches as well

r=me with the whitespace fixed ;-)

Comment 7

[David :Bienvenu]

fixed, summary changed to reflect that the issue affects saved searches in general.