Re: Opening mailboxes

Hello Peter,

On 2/18/20 11:00 AM, Peter Bloomfield wrote:
> Hi All!
>
> Balsa gives the startup option of opening every mailbox that was open 
> at the end of the previous session: "Remember open mailboxes between 
> sessions". Because opening a mailbox can be time-consuming, the 
> operations are carried out in threads, but to avoid overloading the 
> machine, a mutex is used to actually execute only one thread at a time.
>
> I've just pushed to GitLab a different approach, using a pool of 
> threads managed by GLib, which simplifies much of the process. To 
> mimic the previous strategy, the pool actually has just a single 
> thread, so that mailboxes are opened in turn. We could be less 
> conservative: GLib can report the number of "processors" available (4, 
> on my laptop), and any number of threads up to that could presumably 
> be used without overloading the machine. That would give the user a 
> responsive UI sooner.
>
> Any thoughts about the number of threads?
>
> Thanks,
>
> Peter
Even on my previous, single processor PC, I don't recall noticing any 
great delay or lag in starting up Balsa, and I keep six to nine 
mailboxes open, most with dozens to hundreds of messages, but two with 
over 2000 messages each.  I suspect this will only be a problem on 
older, smaller, lower powered PCs.

That said, the issue of how many threads to open is also asked when 
compiling - the -j option to make (I don't remember if make actually 
handles it or passes it to gcc.)  It also exists at a higher level on 
Gentoo, telling emerge (the package manager) how many packages it can 
install (including compile) at the same time.  The distcc docs also 
discusses the same thing.  All seem to use both the number of threads as 
well as a maximum load average at which to start a new job or thread.  
Most of them seem to suggest a thread count of somewhere between then 
number of cores to twice that plus one or two, which sounds to me like 
it's getting to be a religious argument.

The one thing I'm sure you thought of - these mailbox opening threads 
are unlikely to be compute bound, but might well be IO bound, especially 
if all the mailboxes are on the same physical disk.  Too bad there isn't 
an IO equivalent of load average. However, given this issue, I'm not 
sure allowing multiple threads will actually speed up the overall 
process.  I'm also not sure how easily this can be tested, given the 
possibility of disk caching. I'm certainly willing to do some testing, 
if it's likely to be at all useful.  (I currently use mirrored spinning 
rust, no SSDs yet.)

Jack