Re: X performance suffers under emacs 21.1.1

[Daniel Ortmann]

ShengHuo ZHU <address@hidden> writes:

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

Whoa!  A surprise.  Apparently *uuencoded* and *mime* article images
have vastly different display times.

A) The first time I reran the test from an nnml group I recorded: "27.0
   seconds when displaying from an nnml group, virtually as fast as
   running the external munpack + xv combination."

   From: Max <address@hidden>
   Subject: 1955 Porsche 550 Spyder (1998 Beck Replica) blue silver-fV=mx=.jpg 
(1/1) 102838 bytes
   Organization: TonyO Consulting
   Newsgroups: 
alt.binaries.automobiles,alt.binaries.pictures.auto,alt.binaries.pictures.automobile
   Message-ID: <address@hidden>
   Date: Wed, 21 Nov 2001 15:29:53 GMT
   NNTP-Posting-Host: 142.173.19.84
   
B) Then I realized I used a similar article which was the almost exactly
   the same size, but NOT identical ... so I reran the test with the
   exact same article as formerly.

   ... The surprise is that this time it took only 9 seconds!

   Rerunning the test in A) gave me 19.0 seconds the second time instead
   of 27 seconds.

   Rerunning the first test in B) again took only 6 seconds.

   The difference seems to be that the slow article is uuencoded, and
   the fast one is mime.

C) 133MHz Cyrix processor (a 100MHz Cyrix part labeled as IBM and
   overclocked to 133MHz) / machine / memory info:

    FreeBSD 4.4-STABLE #0: Tue Sep 25 13:50:53 CDT 2001
        address@hidden:/usr/src/sys/compile/PYRL
    Timecounter "i8254"  frequency 1193182 Hz
    CPU: Cyrix 6x86 (486-class CPU)
      Origin = "CyrixInstead"  DIR=0x1531  Stepping=1  Revision=5
      CPU cache: write-through mode
    real memory  = 67108864 (65536K bytes)
    avail memory = 62443520 (60980K bytes)
    pci0: <S3 Trio graphics accelerator> at 8.0 irq 11
    vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
    sc0: VGA <16 virtual consoles, flags=0x300>


>> 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".

Oops, my bad.

I meant to type, "require a change to the documentation displayed when
C-h k g is pressed in a gnus summary buffer".

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