Re: [Evolution-hackers] Performance with Exchange 2003

[Not Zed <notzed ximian com>]

On Sat, 2005-05-07 at 20:39 -0400, Lee Revell wrote:
> 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.

Oops.  Thats just a bug in the patch.  The old code used to iterate over each summary item from the live summary - when you remove a summary item by index it reduces the length of the summary, so i needs to be decremented too.

Actually there is another bug there, it should do camel_folder_summary_remove(, mi); since the index wont match except for perhaps the first remove.  I guess there may be other similar problems around that section of code.

>  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?

Hmm, perhaps it could emit a null query.  It still wont fix the search problem.

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 ...