Re: [Evolution-hackers] Performance with Exchange 2003

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];
 991                         if (mi->real->summary == ssummary) {
 992                                 char *uid = (char *)camel_message_info_uid(mi);
 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                 }        

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?

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]