Re: [Evolution-hackers] Performance with Exchange 2003

[Lee Revell <rlrevell joe-job com>]

On Wed, 2005-05-04 at 12:25 +0530, Not Zed wrote:
> On Fri, 2005-04-29 at 19:06 -0400, Lee Revell wrote: 
> > I was wrong about the impact of the search bar bug relative to the
> > hidejunk issue, but it's impossible to deny that the above numbers
> > represent a problem.
> 
> Indeed.  It looks to me like lock contention still.  You have two
> threads getting the same lock and freeing it in a small loop - you end
> up getting many more context switches than normal, and orders of
> magnitude slow-down as you are seeing here.  Perhaps when the search
> function is retriving each messageinfo while the messagelist is doing
> the same.  I haven't been able to recreate this so far.  vFolders were
> streamlined somewhat in 2.2, that may have had an effect too.
> 
> I will look into it when i can, I've been busy with meetings lately.
> 

Thanks for taking this seriously, I was afraid I was getting blown
off ;-)

> I'm concerned that even though your patch fixes this symptom, the
> problem is still in the code somewhere.  So even though the 'normal'
> case will be fixed, if the user sets a search for example, it will
> re-expose the underlying problem. I'd rather have that get fixed too,
> and not just the common case.
> 

Indeed, I have found this to be the case.  Even with my patch,
regenerating the message list can take absurdly long sometimes,
typically when clearing a previous search.

> It would be really handy if you could get a backtrace of WHEN it is in
> the middle of one of these >10 second update times(i.e. ctrl-c while
> it is running slow).  Of all threads (thread apply all bt).  That
> should show clearly what all threads are doing and help pinpoint how
> the lock contention (if indeed, thats what it is), is happening.  The
> other trace only has 1 thread, and doesnt show anything other than
> normal expected operation either.  I am guessing a code walkthrough
> will also pick this up, but a backtrace will reduce the doubt and
> search time.

That backtrace was from such a time, and I have found a few spots where
that code path can be optimized a bit.  Specifically there are a few
more places where searches for "" can be better optimized away, that my
patch definitely hides.  It does look like lock contention could be the
main problem.  I'll get a complete backtrace ASAP.

Lee