Re: Speed difference in Gnus
On Thu, Oct 13 2005, Hrvoje Niksic wrote:
The speed difference between XEmacs and GNU Emacs is amazing, in
that
GNU Emacs is significantly faster, at least for "heavy" usage such as
Gnus.
Interesting. Which versions of (X)Emacs and Gnus did you test?
Entering a large summary buffer takes time proportional to the
*square* of the number of messages in the folder. (This is not a
wild guess, a friend has actually measured.) Time to enter a folder
of more than 3000 articles quickly degrades to minutes.
For the longest time I believed this to be a result of XEmacs's
implementation of text properties on top of extents. I planned to
convert Gnus to use extents natively, in the hope that it would speed
up summary buffer generation.
Then `M-RET' should be significantly faster, shouldn't it?
,----[ <f1> f gnus-group-quick-select-group RET ]
| gnus-group-quick-select-group is an interactive compiled Lisp
| function in `gnus-group.el'.
| (gnus-group-quick-select-group &optional ALL)
|
| Select the current group "quickly".
| This means that no highlighting or scoring will be performed.
| If ALL (the prefix argument) is 0, don't even generate the summary
| buffer.
|
| This might be useful if you want to toggle threading
| before entering the group.
`----
But according to profiling, most of the time is spent in
`insert',
at least once you discount excessive GC by increasing
gc-cons-theshold. I'm not sure what XEmacs is doing wrong here. I
suspect Mule is to blame, but I can't prove it.
`C-u 0 M-RET' probably doesn't use insert so often. Is it comparable
to `C-u 0 M-RET' in Emacs then?
Using FSF Emacs gave me an order-of-magnitude speedup when entering
large newsgroups and large mailing list folders. It's uncanny.
Bye, Reiner.
PS: Cc-ing ding. This might be interesting for Gnus developers. See
http://thread.gmane.org/gmane.emacs.xemacs.beta/20690 for the
whole thread.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/