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 _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
