Re: set time_inc= ?

[Kyle Wheeler <kyle-mutt@xxxxxxxxxxxxxx>]

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

On Wednesday, May 28 at 09:56 AM, quoth Wilkinson, Alex:
> Ok so in the manual time_inc says:
>
>  "this variable controls the frequency with which progress updates 
>  are displayed. It suppresses updates less than ``time_inc'' 
>  milliseconds apart. This can improve throughput on systems with 
>  slow terminals, or when running mutt on a remote system."
>
> Ok so what is meant by "progress updates" ?

Whenever mutt does something that can take a while (such as download a 
large message, open a very large mailbox, send a large message, etc.), 
it displays status information about that task at the bottom of the 
terminal. That status information is a "progress update".

> I'm still trying to work out what time_inc gives me :(

time_inc is a solution to a problem that some people have had. Here's 
how things used to work:

Progress updates used to be on a "once every N things" basis (this is 
the $read_inc setting). For example, when opening a large mailbox, you 
could tell mutt to post a new progress update every 10 messages (ten 
is the default, but it could be any number). Thus, after parsing ten 
messages, mutt would change the message at the bottom of the terminal 
("update" it) to tell you that another ten messages had been parsed. 
Now, generally speaking, mutt can read messages out of a mailbox 
pretty darn fast. Let's say, just for discussion purposes, that on you 
computer, mutt can read 1000 messages every second. With a $read_inc 
setting of 10, that means mutt will attempt to update the terminal's 
contents 100 times per second, or once every 1/100th of a second. 
That's pretty darn fast---you can't even read that fast---and some 
terminals just aren't that fast. If your terminal is slow and can't 
change it's display that quickly, you're spending a lot of time 
(comparatively speaking) updating your terminal and you aren't even 
getting anything useful out of it because the terminal can't display 
updates that quickly. It can even slow down how quickly mutt opens a 
mailbox, because mutt can't change the display until the previous 
display has finished. If your terminal has a reaction time of 1/25th 
of a second, that means updating the terminal 100 times takes 4 
seconds! That's no good, because that forces mutt to take four times 
as long to open a 1000 message mailbox (which it could have opened in 
1 second, if it didn't have to wait for the terminal). With me so far?

Previously, to compensate, you would do something like increase the 
read_inc setting to, say, 100. Thus, mutt would attempt to update the 
terminal's contents only 10 times per second. That's still plenty 
fast, on your 1/25th second terminal, it only takes 0.4 seconds, which 
means mutt can easily meet its deadline of opening the 1000 message 
mailbox in 1 second.

But now imagine that in addition to opening a local mailbox, which 
mutt can open quickly, you also want to open a remote IMAP mailbox, 
which mutt can only pull down much more slowly. Let's say, just for 
argument's sake, that mutt can only read 20 IMAP messages every 
second. If your $read_inc setting is 100, that means mutt has to read 
100 messages before it tells you how far along it is, which means that 
in the IMAP situation, it'll only tell you what it's doing every five 
seconds. That's annoying! It's also very imprecise! You don't know if 
mutt is just chugging along, or if there's one really big message 
that's causing a problem, or quite what's going on. What you'd really 
like mutt to do is to tell you what it's up to every so often, so that 
you know it's still alive, but at a pace that doesn't slow down its 
operation. That's where $time_inc comes in. You can set $read_inc to 
something absurdly small, like 1, and then set $time_inc to something 
reasonable, like 250. That means that it'll update the terminal to 
tell you what it's up to 4 times per second, NO MATTER how quickly or 
slowly it's doing its job. That way you can ensure that mutt keeps you 
informed (even if the task is really slow) without slowing itself down 
(even if the task is really fast).

Does that make sense?

> AFAICT with time_inc=10 included in my $HOME/.mutt/settings I see no 
> change, yet I see people on this list raving about it ? What am I 
> missing ?

A $time_inc=10 setting is absurdly low. That's telling mutt that you 
need updates every 1/100th of a second. You can't read that fast, and 
your terminal can't update that fast. The real joy of $time_inc is 
that you can make your increments (read_inc and write_inc) very small 
(essentially, 1) so that every update is as accurate as possible, but 
your updates still don't occur so fast that your terminal becomes the 
bottleneck and starts slowing mutt down.

But, it's also worth pointing out that if your terminal is blazingly 
fast (e.g. an xterm or rxvt or something like that), you may never 
notice any difference in performance, because the terminal is never 
slowing mutt down.

~Kyle
- -- 
A man cannot be held responsible for what his mind does while he's 
asleep.
                                                     -- Jean Luc Picard
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iEYEARECAAYFAkg81kkACgkQBkIOoMqOI17fqACg4kOqav/E0YSxNc8kpV320x5T
zDwAnjBz/bE6y/L3zJ4ylf7GzNhqLxN2
=nuG0
-----END PGP SIGNATURE-----