emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: X performance suffers under emacs 21.1.1


From: ShengHuo ZHU
Subject: Re: X performance suffers under emacs 21.1.1
Date: Mon, 10 Dec 2001 15:02:43 -0500
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1.50 (i686-pc-linux-gnu)

Daniel Ortmann <address@hidden> writes:

[...]

> - 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?

Actually, Gnus uses several levels of caches. The one you encountered
is called backlog.  The g key, after the o key, does not really
refetch the article from the NNTP server, but from the backlog buffer,
" *Gnus Backlog*".

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

In most cases, Gnus doesn't refetch from the NNTP server.

> 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?

It is strange. It is pretty fast (about 3 sec) on my machine, even to
show an image of over 600KB. Could you copy the article to a local
backend, e.g. nnml, then type `g' in that group?  Is this faster?  And
could you show me the configuration of your machine? Maybe the speed
of CPU and the size of memory are related.

> 4) Does your new patch, which I installed, require a change to the
>    documentation displayed when C-k g is pressed in a gnus summary
>    buffer, reflecting that "maybe" the article will be refetched?

Do you mean "C-u g"?  Maybe the document show be changed to "force
re-showing".

ShengHuo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]