Re: speed of cacheing depends on terminal?

[Kyle Wheeler <kyle-mutt@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday, May 10 at 06:07 PM, quoth dv1445@xxxxxxxxx:
> 1.5.17 with header caching enabled.  I've got read_inc and write_inc 
> set to 1000.  Nevertheless, I've noticed that the process of 
> evaluating the cache (when I switch into a big folder) is 
> significantly slower when I use Terminal.app than if I use 
> xterm/rxvt over Apple's X11.

That's why they recently added $time_inc (it's not in a released 
version of mutt yet; just in the current development tree). Here's the  
description from the development manual:

     Along with "read_inc", "write_inc", and "net_inc", this variable
     controls  the  frequency  with  which  progress updates are dis-
     played. It suppresses updates less than "time_inc"  milliseconds
     apart.  This  can improve throughput on systems with slow termi-
     nals, or when running mutt on a remote system.

> This is puzzling, since I thought caching has nothing to do with the 
> terminal choice.  Anybody know why this would be, and/or how I can 
> do something about it?

Caching doesn't have anything to do with the terminal choice, BUT 
since mutt is single-threaded, it can be slowed down by anything that 
requires updating the display. No operations in mutt can happen at the 
same time, so mutt has to pause what it's doing (e.g. caching) to 
update the terminal. If the terminal is slow, that pause can take 
longer, and will make the total action take longer.

Put another way, the length of time required to do a given complex 
action is the sum of all time required to perform the components of 
that action. In the example of updating the cache, you are also asking 
mutt to update the display. In the simple example of a folder with 
1000 messages, if read_inc is 1, you are asking mutt to update the 
display 1000 times, so the length of time required to cache those 1000 
messages is the sum of the time to read 1000 messages, the time to 
write the necessary information to the cache, and the time to update 
the terminal 1000 times. Thus, the way to reduce the impact of a slow 
terminal is to make mutt update the terminal less often---by 
specifying a $read_inc of, say, 50 or 100. Using $time_inc allows mutt 
to condense display updates that are close together in time into a 
single display update, which reduces the impact of a slow terminal 
without reducing the granularity of the display (as increasing 
$read_inc does).

> FWIW: I built using the BerkeleyDB libraries, since the other 
> choices refuse to work with OSX.  (Actually, I finally got mutt to 
> build with gdb, but mutt behaved *really* weird with screen-drawing, 
> so gdb is a no-go on OSX).

I use qdbm on my Mac and am very happy with it (it's *really* fast). 
If I recall correctly, several people have discovered odd performance 
problems with BerkeleyDB on OSX.

~Kyle
- -- 
Those who profess to favor freedom, and yet depreciate agitation, are 
men who want rain without thunder and lightning.
                                                  -- Frederick Douglass
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iEYEARECAAYFAkgnEosACgkQBkIOoMqOI172kACfTBzoMsAbrlREUDg05X77MGbv
1n0An1J5vuIywkXM8yur3obrHA5pQhf9
=fXd9
-----END PGP SIGNATURE-----