On Wed, 2005-05-11 at 09:46 +0530, Not Zed wrote: > If the search can take ~0.1 second, but it sometimes takes 10 seconds, > it isn't the fact that it is searching a null search that is causing > it to take 10 seconds ...
I think this may be related to what else Evo is doing. For example, every time a folder changes, the Unmatched vfolder is rebuilt, which is something like an O(N) operation where N is the total number of messages in all folders. On startup, it's worse - when it first builds the Unmatched vfolder, for each real folder it scans, to build the vfolder, it iterates over all the messages that were previously in the vfolder. So if you have 100,000 messages total, distributed over 20 folders of 5000 messages each, you scan 5000 headers, then 10000, then 15000, etc until the folder is built. Then for each folder change you scan all 100000 messages. Also I don't think it ever takes 0.1s. The patch I posted times all folder searches, not just Unread. To generate the numbers I posted, I switched back and forth between Unread and Inbox, so the lower numbers were probably for scanning Inbox. I know, it's strange. I spent a whole day poring over it with gdb, trying to identify any lock contention issues, and could not come up with anything definite. Anyway, I think I still need to re-implement hidejunk in an efficient way for the patch to be acceptable - there's no point in changing the search bar until this is done. Lee Lee _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
