Re: [Evolution-hackers] Performance with Exchange 2003

[Lee Revell <rlrevell joe-job com>]

On Wed, 2005-04-27 at 10:02 +0530, Not Zed wrote:
> On Wed, 2005-04-27 at 00:22 -0400, Lee Revell wrote: 
> > On Wed, 2005-04-27 at 09:26 +0530, Not Zed wrote:
> > > A search for "" is alway optimised anyway, it doesn't actually perform
> > > any comparisons.
> > 
> > Then where does the *massive* speedup come from?  Have you actually
> > tried my patch?
> 
> I haven't so far; for starters it doesn't maintain all the
> functionality.  But I did try to recreate the slowness you were fixing
> - so i had something to compare to.  I can't really see it myself, it
> doesn't seem any slower changing to the unread vfolder vs any other
> folder, and most of the time doing either is building the nodes for
> the etreemodel.
> 
> I guess you must have some other option set that I don't, which is why
> i'm not seeing this speed problem.  e.g. hiding deleted messages, or
> some other view option.  Or a particularly large message set? (>200K)
> Or lots of folders? (>100)  Or a slow machine/with little memory?
> 

I do have a slowish machine (600 MHz) combined with a large message set
(~110K messages) and about 50 folders.

I have a patch that retains the full functionality by making "hide junk"
configurable, but it's not quite ready to post.

The maximum speedup will be seen by disabling "hide junk" and "hide
deleted" combined with my search bar fix.  With this combination, I
expect the difference to be noticeable even on the fastest machines.

I can see the code section that 'optimizes away searches for ""' but you
still burn a *lot* of CPU parsing headers before getting to that point.
My profiling showed a heck of a lot of time in strncasecmp() with a null
search, which I then verified by code inspection, and with the debugger.

I am confident that the difference will be indisputable once I have
finished the patch and more people with slower machines try it.

Anyway, this problem is almost certainly unrelated to the OP's Exchange
issue.

Lee