Re: X performance suffers under emacs 21.1.1

[Daniel Ortmann]

ShengHuo ZHU <address@hidden> writes:

> Daniel Ortmann <address@hidden> writes:

>> 2) ... After pressing o to download and THEN pressing enter to view
>> the article, I expected that the article's content would be processed
>> in the normal way.  I.e. I expected the image to be displayed, but
>> the uuencoded text was shown instead.

> `o' displays the article in raw mode, i.e. what you saw is base64
> encoded text (not uuencoded text, I guess).  RET is bound to
> gnus-summary-scroll-up, which does not mean to redisplay the article.
> What you want is `g' (gnus-summary-show-article).

Ok, here is what I found out testing with the following test article
over my 28.8k line:

    From: Max <address@hidden>
    Subject: 1955 M-B 300b Cabriolet D-maroon-fV=mx=.jpg (1/1) 402783 bytes
    Newsgroups: 
alt.binaries.automobiles,alt.binaries.pictures.auto,alt.binaries.pictures.automobile
    Lines: 8957
    Message-ID: <address@hidden>
    Date: Tue, 20 Nov 2001 07:13:59 GMT

- pressing o
- 203 seconds
- saw minimode download info

- pressing g (right after o on the same article)
- 68 seconds
- saw no minimode download info

- manually running munpack on the saved article, xv, exiting and checking time
- 23 seconds

I am experiencing cognitive dissonance.  These numbers don't make sense
to me.  The g supposedly "refetches" the article (which is the subject
of my original bug report), but there is no way that the article was
actually "refetched" over the modem line in 68 seconds.

... And yet, the 68 seconds is very slow compared to the 23 seconds
needed to process the article myself.  Note that the 23 seconds
involved manually running date, switching buffers to dired, running
munpack, refreshing the dired buffer, running xv, exiting xv, running
date again, etc.  There was considerable manual overhead involved in
that 23 seconds.

Questions:

1) Is the g key, after the o key, *really* refetching the article?  Is
   the document incorrect?  Or does "refetch" mean something unusual?

2) Is there a way to reprocess the article after running o *without*
   refetching the article?

3) Assuming that g after o does not actually refetch the article but
   merely redisplays the images, why is it so slow compared to manually
   running munpack and xv?  Can anything be done to speed this up?

-- 
Daniel Ortmann, 2414 30 Av NW, #D, Rochester, MN 55901
address@hidden (h)   / 507.288.7732 (h)
address@hidden (w) / 507.529.3887 (w)