Re: set time_inc= ?
Pure gold kyle! Thanks stacks for such a detailed explanation.
<forgive my top-posting>
-aW
0n Tue, May 27, 2008 at 10:49:29PM -0500, Kyle Wheeler wrote:
>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.
IMPORTANT: This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT
1914. If you have received this email in error, you are requested to contact
the sender and delete the email.