Re: [Evolution] Evolution performance

[Adam Tauno Williams <awilliam whitemice org>]

On Wed, 2014-05-28 at 12:25 -0400, Reid Vail wrote:
> Hello Adam -
> Thanks for the advise.  
> Answering your earlier question, yes there is about 500meg, I think,
> in local mail (inbox) and at least that much more in folders.  The
> Inbox is of course under "On this computer", but so are all of the
> folders.  I'm not sure if that's part of the problem or not.
> I can't tell for sure if 3.6.4 is mbox or maildir.  I've looked for
> documentation and haven't been able to figure that out yet.  I think
> it's maildir.  And I'm honestly not sure what the steps would be to
> migrate from mbox to maildir.

It is probably maildir, so not a problem there.  Only way it would be
mbox is if you upgraded the account from Evolution 2.x.

> I have tried a few of your suggestions; purging the .cashe and also
> emptying the trash but there didn't appear to be performance impact.

Nope, if the mail is under "On this computer" the cache shouldn't be the
issue

> I did try a different tack; I installed Mint17 on Vituralbox,
> installed Evolution (rev 3.10.4, migrated my wife's mail data to that
> and saw a big improvement. 

GOOD MAN!  Testing in a virtual machine before breaking things!!!! Man,
I wish more people would take that approach! :)

Indeed, the post 3.6.x releases of Evolution are in my experience each
noticeably more responses than the last.  3.8.x was a big improvement.

> But there are major differences in her architecture and mine.  I have
> much faster CPU and a SSD drive.  So, I think my plan is this.... get
> her on a an upgraded OS, install the new Evolution and see if that
> helps.  If not, put in an SSD, and then upgrade the CPU if needed.
> Does that make sense?

Data on an SSD never hurts. :)  The CPU seems an unlikely culprit,
anything even a few generations old probably has plenty of HP for a
desktop.  Kludegy I/O subsystems kill responsiveness.  If you can watch
with top, or even better dstat, when Evolution starts then you can see
if you begin paging and just to see the general I/O pattern - we are
interested in disk & memory, not really so much with CPU [a saturated
I/O subsystem can spike CPU utilization - making CPU *look* like the
bottleneck when the spike is actually an effect not a cause].

These tests work best [are most telling] after a cold start or flushing
the buffers.  

   sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

The above makes LINUX forget what it has buffered, and [nearly anyway]
start from scratch - which keeps things it has previously cached from
messing up test results.

You can also watch I/O in extreme detail:
<http://www.whitemiceconsulting.com/2011/04/blockdump-logging.html>

Otherwise beyond I/O the debugging page is always a good read:
<https://wiki.gnome.org/Apps/Evolution/Debugging>


-- 
Adam Tauno Williams <mailto:awilliam whitemice org> GPG D95ED383
Systems Administrator, Python Developer, LPI / NCLA