Re: [Evolution-hackers] Performance with Exchange 2003

[Lee Revell <rlrevell joe-job com>]

On Fri, 2005-05-06 at 17:14 +0530, Not Zed wrote:
> On Thu, 2005-05-05 at 21:34 -0400, Lee Revell wrote: 
> > On Thu, 2005-05-05 at 13:53 -0400, Lee Revell wrote:
> > > On Thu, 2005-05-05 at 11:53 +0530, Not Zed wrote:
> > > > Could you try the attached patch to camel?  It removes most of the
> > > > one-at-a-time stuff from the core camel objects.
> > > > 
> > > > It might make a difference, or it might not - there patches of code in
> > > > mail which might need similar treatment.
> > > 
> > > The patch did not seem to make a difference.  Here's a full backtrace.
> > 
> > As a matter of fact, the patch causes Evolution to consume 100% of the
> > CPU.  It would appear that the locking is still buggy.  I'll post more
> > info if I can get it.
> 
> I wonder where.  Its probably that the patch is buggy, not the
> locking.
> 

I think I found the bug, although I don't quite understand it.

Unless I remove the i-- on line 998, it will get stuck in this loop
forever.  It's hard to see how this ever could have worked.

 985         if (folder_unmatched != NULL) {
 986                 /* scan unmatched, remove any that have vanished, etc */
 987                 sarray = camel_folder_summary_array(((CamelFolder *)folder_unmatched)->summary);
 988                 for (i=0;i<sarray->len;i++) {
 989                         CamelVeeMessageInfo *mi = sarray->pdata[i];
 990 
 991                         if (mi->real->summary == ssummary) {
 992                                 char *uid = (char *)camel_message_info_uid(mi);
 993 
 994                                 if (g_hash_table_lookup(allhash, uid+8) == NULL) {
 995                                         /* no longer exists at all, just remove it entirely */
 996                                         camel_folder_summary_remove_index(((CamelFolder *)folder_unmatched)->summary, i);
 997                                         camel_folder_change_info_remove_uid(folder_unmatched->changes, camel_message_info_uid(mi));
 998                                         i--;
 999                                 } else {
1000                                         g_hash_table_remove(allhash, uid+8);
1001                                 } 
1002                         }        
1003                 }        
1004                  

With the above fix and your patch, it's a little bit faster (the
searches take 10s at most), but I still think the problem is that we are
doing the search in the first place.

Can you please explain why the search bar emits this query when the text
field is NULL?

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

Shouldn't it emit a null query if the text field is empty?  And even if
this is correct, and the above query is supposed to be optimized away,
why do we still run it against every single header?

Lee