'0.95 /slow to open large (1009K) messages

'0.95 /slow to open large (1009K) messages

[Harry Putnam]

I've just noticed while opening large cron daemon messages, a very
lengthy pause.

The messages run around 20,000 lines "wc" shows:
$ wc  <big-cron
19861   19922 103290
So, app. 1009K of data.

Gnus takes a full minute to open one of these. (timed at 59.6 seconds).
Mutt opens them instantly.

I'm sure gnus is doing a lot more work than mutt, but still this seems
too long.  What do other people see when opening a large message?  Is
this normal?

Re: '0.95 /slow to open large (1009K) messages

[Karl Kleinpaste]

Delays in opening very large messages are somewhat routine.  Mutt
opens them instantly because mutt is rather stupid and doesn't do
1/100th of what Gnus does with them.  Consider that e.g. Gnus is
seeking emphasizable text (*bold* _underline_ /italic/) text to toy
with, hunting for URLs to highlight, examining them for embedded
uuencoded data, and Lars alone knows what else.  Each of these
operations has to massage the entire message body.

Granted that a minute seems rather a long time.  But then most of this 
kind of processing is being done by regexp search followed by property 
hackery and so forth -- not really the fastest-acting options around,
usually needing a fair amount of interaction with the X server as well.

I don't believe there are any particularly new sources of slowness in
p0.95.  If you think there might be, I suggest you revert temporarily
to an older version (say, around the p0.84 range) and compare timings.

Re: '0.95 /slow to open large (1009K) messages

[Harry Putnam]

Karl Kleinpaste <karl@justresearch.com> writes:

> Delays in opening very large messages are somewhat routine.  Mutt
> opens them instantly because mutt is rather stupid and doesn't do
> 1/100th of what Gnus does with them.  Consider that e.g. Gnus is
> seeking emphasizable text (*bold* _underline_ /italic/) text to toy
> with, hunting for URLs to highlight, examining them for embedded
> uuencoded data, and Lars alone knows what else.  Each of these
> operations has to massage the entire message body.
> 
> Granted that a minute seems rather a long time.  But then most of this 
> kind of processing is being done by regexp search followed by property 
> hackery and so forth -- not really the fastest-acting options around,
> usually needing a fair amount of interaction with the X server as well.
> 
> I don't believe there are any particularly new sources of slowness in
> p0.95.  If you think there might be, I suggest you revert temporarily
> to an older version (say, around the p0.84 range) and compare timings.


Man that was a fast response Karl...

I'm off to work in a few minutes so I'll try some older versions this
evening.   One further question:

The messages is a lengthy report of a cron run tar backup.  Most of
the lines in the message have the format of a long pathname/file
like so:

/home/reader/News/agent/nntp/netnews.worldnet.att.net/comp/lang/awk/9362
/home/reader/News/agent/nntp/netnews.worldnet.att.net/comp/lang/awk/9363

Would this cause any of the many operations gnus does to be
particularly slow?

Re: '0.95 /slow to open large (1009K) messages

[Andrew Markebo]

Maybe some option like 'don't do fineprinting of messages larger than
xyzzy bytes' or similar?

	/andy

Re: '0.95 /slow to open large (1009K) messages

[Colin Rafferty]

Harry Putnam writes:
> Karl Kleinpaste <karl@justresearch.com> writes:

>> Consider that e.g. Gnus is seeking emphasizable text (*bold*
>> _underline_ /italic/) text to toy with, hunting for URLs to
>> highlight, examining them for embedded uuencoded data, and Lars
>> alone knows what else.  Each of these operations has to massage the
>> entire message body.

> The messages is a lengthy report of a cron run tar backup.  Most of
> the lines in the message have the format of a long pathname/file
> like so:

> /home/reader/News/agent/nntp/netnews.worldnet.att.net/comp/lang/awk/9362
> /home/reader/News/agent/nntp/netnews.worldnet.att.net/comp/lang/awk/9363

> Would this cause any of the many operations gnus does to be
> particularly slow?

I imagine that it will think about italicizing most of that stuff.  If 
you do a `C-u g' on this message, you will see that /slashes/ that are 
italicized.

-- 
Colin

Re: '0.95 /slow to open large (1009K) messages

[Michael Welsh Duggan]

Andrew Markebo <andrew.markebo@telelogic.se> writes:

> Maybe some option like 'don't do fineprinting of messages larger than
> xyzzy bytes' or similar?

All the `treat' options (like `gnus-treat-emphasize') purport (at the
very least) to support an integer value:

  5. An integer: Do this treatment on all body parts that have a length
     less than this number.

-- 
Michael Duggan
(md5i@cs.cmu.edu)

Re: '0.95 /slow to open large (1009K) messages

[Simon Josefsson]

Harry Putnam <reader@newsguy.com> writes:

> I've just noticed while opening large cron daemon messages, a very
> lengthy pause.

The regexp searches takes time, I elp-profiled Gnus and come up with
theese limits.

;; make gnus faster
(setq gnus-treat-buttonize 5000
      gnus-treat-emphasize 5000
      gnus-treat-highlight-signature nil
      gnus-treat-strip-pgp 5000
      gnus-treat-strip-banner 5000)

Re: '0.95 /slow to open large (1009K) messages

[Bruce Z. Lysik]

>>>>> "M" == Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

    M> All the `treat' options (like `gnus-treat-emphasize') purport
    M> (at the very least) to support an integer value:

    M>   5. An integer: Do this treatment on all body parts that have
    M> a length less than this number.

Unfortunately this is 'less than the integer'.  And (not n) doesn't
appear to work either.

(Currently, I'd love gnus-treat-hide-signature to hide all .sigs
greater than X.)

-- 
Bruce Z. Lysik  <eldrik@logrus.com>   http://www.logrus.com/~eldrik
GCS d++(-) a-- C++ ULS+++$ P+++$ L++ E+ W+++ N++ w--- M-- V PS PE
Y+ PGP+ t+ 5++ X+ R+ tv+ b++ DI+ G e++ h+ r y+ s

Re: '0.95 /slow to open large (1009K) messages

[Lars Magne Ingebrigtsen]

eldrik@logrus.com (Bruce Z. Lysik) writes:

> Unfortunately this is 'less than the integer'.  And (not n) doesn't
> appear to work either.

This has been fixed in 0.96.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen