[Users] [Bug 4243] New: Switching folders is slow

[noreply at thewildbeast.co.uk]

https://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4243

            Bug ID: 4243
           Summary: Switching folders is slow
           Product: Claws Mail
           Version: GIT
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Folders
          Assignee: users at lists.claws-mail.org
          Reporter: me at bearbin.net

Currently switching between folders in Claws takes rather longer than I think
it _should_ do. On my machine it takes ~5s to open an IMAP folder with ~100000
messages inside.

I have had a look at the code and there seem to be multiple causes of the
issue:

 1. Folders are always rescanned over the network before being opened. This
contributes several seconds of latency and download time.

 2. Folders (and their constituent summaryviews) are always rebuilt on opening
rather than being cached.

 3. Building 100k GTK rows takes time (not much can be done here...).

 4. Extracting the information required for a summary row from the MsgInfo
struct is expensive.

 5. Threading and sorting are also expensive.

With regards to 1., this seems like rather a design flaw, is there a good
reason behind it? If not, it would make sense if scanning was completed in the
background after the initial render of the folder.

Caching (in RAM) rendered folders as in 2. appears to be a larger architectural
change but would make folder changes effectively instant no matter slow
everything else is.

The code for 4. is relatively efficient, just the volume of messages and
feature set requires that a lot of CPU time be spent on it. But a cache could
be added (in the same vein as the imapcache) to reduce endless recalculations
of unchanged messages.

I ran a profiler over the code for 5. and found two easy changes adding up to
around a 10% CPU saving (of the total for loading a folder) - I can supply the
patches for the changes. With some more substantial architectural changes I
think another 5-10% at least could be saved. 

Any thoughts?

-- 
You are receiving this mail because:
You are the assignee for the bug.