GNOME Bugzilla – Bug 584602
opening a folder does too much disk IO
Last modified: 2014-05-03 10:42:09 UTC
Please describe the problem: When evolution opens it accesses a large amount of data from disk. On my INBOX this takes several minutes to process. The scanned message phase takes a few seconds at the end of this large amount of data processing. Filtering messages can then be slow too, for what I assume is the same root cause. My inbox has 111K messages in it. Steps to reproduce: Presumably, get 111K messages in a folder, and open it with a cold disk cache. Actual results: Expected results: Does this happen every time? Oh yes. Other information:
Which account type? Which exact version?
may be on same lines of bug 583182
bug 583182 probably wants the perf keyword added. It might be related, I can't say for sure. git of evo and evo-data-server as of a few days ago. (I built git to be sure it wasn't fixed before reporting - its been like this for a long time). "IMAP" in Receiving options.
I have an IMAP folder with almost 77K messages, and it opens in less than 6 seconds (with 'open' I mean a time when I click on the folder in the folder list and time when the message list is populated). This is with actual master (~2.30.0). Could you try with the upcoming Evolution 2.30.0+ too, please? Note that here had been done some improvements in the SQLite area, one of them is to use bigger cache, thus it can read data in bigger chunks. Your slowness may also be related in your sort options. There had been done an improvement with text sorting (like when sorting by subject). Could you share your sorting for this folder, please? Thanks in advance.
I'll look at going a build of master to find out. The cache size is a bit of a hack - I already upped my cache size using the persistent cache size setting via the sqlite command line; the fundamental problem has been that evolution touches every message in the folder. If it no longer does that, then the bug is fixed ;) if it still does it, it isn't :> :>. One thing to note though, is that it maybe a bit tricky for me to test this now, as I have recently got a new laptop with an SSD, and it flies!
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Well as I said, its pretty easy to diagnose: watch and see if every message is touched (queried from the folder in sqlite) when opening the folder : thats a terrible scaling factor to have. My new laptop is sufficiently fast I don't particularly care, but anyone on spinning platters is likely to care a great deal. As for sort order, I missed that - it was 'date received' with newest at the top. I do intend, at some point, to roll a master build and add enough instrumentation to trivially debug this, but I don't think its true to say I haven't provided the info needed. I've previously looked deeply into the sqlite cache size - but that is fundamentally a workaround for inefficient algorithms, and nowhere near scalable enough for serious mail management.
I don't see how this ticket is currently actionable. :( Does the problem still exist in 3.10?