Oort Gnus on emacs 20.7 a _lot_ faster than Gnus on XEmacs 21

Oort Gnus on emacs 20.7 a _lot_ faster than Gnus on XEmacs 21

[Steinar Bang]

Platform: P133MHz, 20MB RAM, debian woody, GNU emacs 20.7, XEmacs 21.4
          Oort Gnus v0.04 (CVS update from yesterday)

I recently started running Gnus on a fairly slow piece of computing
machinery: a DEC HiNote Ultra II laptop, with a 133MHz Pentium
processor, and 20MB of RAM.

I'm running GNU Emacs and XEmacs directly from the consoles, since I
have so far been unsuccessful in creating a working XF86Config-4 file.

Since I have been using XEmacs for my Gnus'ing, I continued to do so
on this laptop.  My problem is that Gnus run too slowly to be usable
in XEmacs on this machine.  The least provocation (like eg. 5
keypresses in a row in the *Summary* buffer) sends XEmacs into garbage
collection, where it stays for a minute, and if I wish to open a
folder with 2000 unread, I might as well let it run overnight.

GNU emacs, with the exact same Gnus, is fairly fast.  It rarely enters
garbage collection, and a folder with 2000 unread articles, opens in
about 10 seconds.

Is this kind of performance difference between GNU Emacs and XEmacs
common?  Or is this just very visible on a machine as slow as the one
I'm using?  Is the problem the lack of physical memory?

Or is there something in the current CVS Gnus, something that
provocates a lot of garbage collection in XEmacs?

Re: Oort Gnus on emacs 20.7 a _lot_ faster than Gnus on XEmacs 21

[Karl Kleinpaste]

Steinar Bang <sb@dod.no> writes:
> in XEmacs on this machine.  The least provocation (like eg. 5
> keypresses in a row in the *Summary* buffer) sends XEmacs into garbage
> collection, where it stays for a minute
...
> GNU emacs, with the exact same Gnus, is fairly fast.  It rarely enters
> garbage collection

What value do you have for gc-cons-threshold in each?

Re: Oort Gnus on emacs 20.7 a _lot_ faster than Gnus on XEmacs 21

[Steinar Bang]

>>>>> Karl Kleinpaste <karl@charcoal.com>:

> Steinar Bang <sb@dod.no> writes:
>> in XEmacs on this machine.  The least provocation (like eg. 5
>> keypresses in a row in the *Summary* buffer) sends XEmacs into
>> garbage collection, where it stays for a minute
> ...
>> GNU emacs, with the exact same Gnus, is fairly fast.  It rarely
>> enters garbage collection

> What value do you have for gc-cons-threshold in each?

400000 in GNU Emacs, and 500000 in XEmacs.

Re: Oort Gnus on emacs 20.7 a _lot_ faster than Gnus on XEmacs 21

[Simon Josefsson]

Steinar Bang <sb@dod.no> writes:

> Platform: P133MHz, 20MB RAM, debian woody, GNU emacs 20.7, XEmacs 21.4
>           Oort Gnus v0.04 (CVS update from yesterday)
>
> I recently started running Gnus on a fairly slow piece of computing
> machinery: a DEC HiNote Ultra II laptop, with a 133MHz Pentium
> processor, and 20MB of RAM.
>
> I'm running GNU Emacs and XEmacs directly from the consoles, since I
> have so far been unsuccessful in creating a working XF86Config-4 file.
>
> Since I have been using XEmacs for my Gnus'ing, I continued to do so
> on this laptop.  My problem is that Gnus run too slowly to be usable
> in XEmacs on this machine.  The least provocation (like eg. 5
> keypresses in a row in the *Summary* buffer) sends XEmacs into garbage
> collection, where it stays for a minute, and if I wish to open a
> folder with 2000 unread, I might as well let it run overnight.
>
> GNU emacs, with the exact same Gnus, is fairly fast.  It rarely enters
> garbage collection, and a folder with 2000 unread articles, opens in
> about 10 seconds.
>
> Is this kind of performance difference between GNU Emacs and XEmacs
> common?  Or is this just very visible on a machine as slow as the one
> I'm using?  Is the problem the lack of physical memory?
>
> Or is there something in the current CVS Gnus, something that
> provocates a lot of garbage collection in XEmacs?

How much does the machine swap?  XEmacs is probably larger than Emacs
20 so the binary might become too large for the machine..

Try M-x elp-instrument-package RET on gnus, nn and mm to find out what
is taking so much time to enter the group -- one from Emacs and one
from XEmacs would be useful for comparison.