[Evolution-hackers] vfolder performance problems

[Lee Revell <rlrevell joe-job com>]

I have found the bug that has been causing severe performance problems
with vfolders, "Unread Mail" in particular.

regen_list_regen gets invoked every time a new message comes in.

3415         if (m->search) {
3416                 expr = alloca(strlen(m->search) + 64);
3417                 sprintf(expr, "(and (match-all (not (system-flag \"deleted\")))\n %s)", m->search);
3418         } else
3419                 expr = "(match-all (not (system-flag \"deleted\")))";
3420 }      
3421 searchuids = uids = camel_folder_search_by_expression (m->folder, expr, &mm->ex);

Unfortunately, an empty filter expression (like the default) is treated
as a valid search pattern.  So every time you switch to or from the
"Unread Mail" vfolder, Evolution recursively searches all your mail
folders for this expression:

  (or
        (match-all (header-contains "Subject"  ""))
       	(match-all (header-contains "From"  ""))
  )

To make matters worse, the check_header function in
camel/camel-folder-search.c doesn't immediately match the empty pattern,
it proceeds to extract the specified header from the message before
finally realizing that every possible string will match.  This is why my
profiling was showing so much time in strcasecmp().

Fixing camel/camel-folder-search.c (and camel/camel-filter-search.c) to
immediately return success on an empty search string helps quite a bit.
But the real fix is not to process empty search strings.  I hacked
regen_list_regen to ignore the search input, and the unread mail folder
is finally usable like the other folders.  It's still periodically
scanning all the message recursively to check the junk  and deleted
status, but 'system-flag' expressions seem to be much faster than
'header-contains'.

I have not looked at the GUI code yet, but it seems like the right fix
is to have the interface pass a null search expression if the search
string is null.

Lee