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:awill...@whitemice.org> GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
