Re: performance issues with large numbers of folders

[Peter Bloomfield <PeterBloomfield bellsouth net>]

On 08/19/2003, Noah Levitt wrote:
> Hi,
> 
> I’m a mutt user, but I want to use balsa, because a terminal
> program can’t support the type of i18n that gtk+ programs
> can. But so far, I’ve run into performance problems that
> prevent me from switching.
> 
> I have about 4000 folders under ~/mail. There are a number
> spots where balsa hangs because of this. Here are a couple I
> have noticed (hopefully the only ones):
> 
>   • config_views_load, config_views_save: It appears that
>     there is at least one configuration key for every
>     folder, and these functions iterate over each of them.
> 
>     config_views_load runs at startup before the gui pops
>     up.
> 
>     config_views_save runs when you close the app, before
>     the gui disappears.
> 
>   • scan_mailboxes_idle_cb: Traverses the entire tree of
>     mailboxes.
> 
>     scan_mailboxes_idle_cb runs at startup after the gui
>     pops up, but the whole gui waits on it and appears
>     frozen (it doesn’t make the little progress bar go).
> 
> Each of these takes over 15 seconds on my machine, perhaps
> up to a minute.
> 
> I can see at least four possible solutions to the problem:
> 
>   • change balsa so that these things aren’t needed or work
>     differently somehow

[ 3 other possibilities snipped ]

There's some room for reducing the performance impact of mailbox  
views. Balsa uses them to store user choices about individual  
mailboxes, like sort column and direction, and also the state of  
the folder tree, like which mailboxes are open and/or visible.

In principle, each mailbox has a view, and that's how Balsa  
currently implements them. New mailboxes get a view with a  
default set of values, however, and until these are changed, the  
view doesn't need to be realized. Likewise, as Darko points out,  
if the view is non-default but isn't changed in the session, the  
copy saved in the config file doesn't need to be updated.

If we take advantage of these opportunities, both the number of  
views created in a session, and the volume of access to the  
config file, can be reduced. The price would be more complicated  
methods for getting values from the (possibly default) view, and  
some overhead in tracking which realized views have actually  
changed.

Does anyone see any potential issues with this direction?

Peter