slow splitting

slow splitting

[Chris Jones]

I'm running Red on a NetBSD/mac68k box.  It's running at 16MHz.
Consequently, things get a bit slow...  Anyway, I've noticed that my
blood pressure stays much lower if I know what the program is doing
that is making it take so long.  Consequently, I put some lambda's on
nnmail-pre-get-new-mail-hook and nnmail-prepare-incoming-header-hook
that give me messages saying, "Sorting message %d..." whenever I grab
new mail.  This makes me happy.

Should I turn these hook expressions into full-fledged patches, and
send them in?  The reason I'm asking is this:  If you're running on a
really fast box (and you have simple splitting rules, which I don't),
those messages could just whiz by you, potentially causing some worry
because the thing's printing messages that you don't get an
opportunity to read.

I hope y'all will forgive me if I'm being too pedantic.

Chris

-- 
-------------------------------------------------------------------------------
Chris Jones                                      cjones@rupert.oscs.montana.edu
           Mad scientist in training...
"Is this going to be a stand-up programming session, sir, or another bug hunt?"

Re: slow splitting

[Karl Anderson]

cjones@rupert.oscs.montana.edu (Chris Jones) wrote:


>Anyway, I've noticed that my
>blood pressure stays much lower if I know what the program is doing
>that is making it take so long.

Now _this_ is something that I'd really like to see throughout emacs.
I remember playing with setting my debugger to something silly, &
debug-on-entry -ing read.

>Should I turn these hook expressions into full-fledged patches, and
>send them in?  The reason I'm asking is this:  If you're running on a
>really fast box (and you have simple splitting rules, which I don't),
>those messages could just whiz by you, potentially causing some worry
>because the thing's printing messages that you don't get an
>opportunity to read.
>
>I hope y'all will forgive me if I'm being too pedantic.

Well, if we're being pedantic, a simple period is enough to indicate
progress.  Then nobody's blood pressure rises because a million
messages are whizzing by & possibly important ones are being lost.
Also, it'll prevent a messages buffer full of a million lines that eats
up memory.  Hey, it might be the straw that breaks the camel's back.

karla@celtech.com      Karl Anderson      <URL:http://www.reed.edu/~karl>

Re: slow splitting

[Sudish Joseph]

Chris Jones writes:
> Should I turn these hook expressions into full-fledged patches, and
> send them in?  The reason I'm asking is this:  If you're running on a
> really fast box (and you have simple splitting rules, which I don't),
> those messages could just whiz by you, potentially causing some worry
> because the thing's printing messages that you don't get an
> opportunity to read.

The jwz-enhanced GNUS that was standard with XEmacs until 19.13(12?)
had a messaging function that tried not to call 'message if messages
occured too close to each other.  I do not recollect if it was based
on time or print-nth-message, but you might look it up if you have 
access to that version of GNUS.

-Sudish

Re: slow splitting

[William M. Perry]

Sudish Joseph writes:
>Chris Jones writes:
>> Should I turn these hook expressions into full-fledged patches, and
>> send them in?  The reason I'm asking is this:  If you're running on a
>> really fast box (and you have simple splitting rules, which I don't),
>> those messages could just whiz by you, potentially causing some worry
>> because the thing's printing messages that you don't get an
>> opportunity to read.
>
>The jwz-enhanced GNUS that was standard with XEmacs until 19.13(12?)
>had a messaging function that tried not to call 'message if messages
>occured too close to each other.  I do not recollect if it was based
>on time or print-nth-message, but you might look it up if you have 
>access to that version of GNUS.

  There is a similar function in the url package that will only do it every
'n' seconds.

-bill