Red Hat Bugzilla – Bug 214387
xemacs is very slow for shell or dired
Last modified: 2007-11-30 17:11:48 EST
Description of problem:
This version of xemacs is very sluggish. M-x shell, and reading a directory
are very slow. I suspect it's because extra debugging is on:
Compiling in support for extra debugging code.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
According to upstream, the effect of extra debugging code is barely measurable
at least as of 21.4, and I'm not aware of why it would be any different in 21.5.
Extra error checking code slows XEmacs down much more, but that's not enabled in
the FE build. One thing to experiment with would be to try building with
--disable-kkcc and see if it has any effect.
2) %bcond_without xft
I believe #1 fixes the speed issue.
#2 was just cause it looks much nicer. Please consider these changes.
Quickly testing --with-debug and --without-debug builds, I don't notice any
speed differences between them in shell, dired, nor other general use. But yes,
21.5.27 is slower than the 21.4 series in quite a few places.
xft is nice and something to look forward into, but it is not ready for general
consumption in 21.5.27. Will revisit when future upstream releases come out;
until then "rpmbuild --rebuild --with xft" is for the adventurous. With current
xft, just a few clicks in the Options->Font Size and Options->Font menus result
in the fonts not changing or menus suddenly displaying "Cannot parse current
font" which is only apparently cured by restarting XEmacs.
How does 21.5.28 look?
Sorry, but I have switched to emacs. I'm using the current emacs cvs
emacs-unicode-2 branch, which supports xft. It seems development on xemacs
has slowed to a crawl, and in the meantime emacs is pretty much 'batteries
included' now, so I have little incentive to use xemacs anymore. (There are a
few features from xemacs I miss, but I can live).
Ok, closing due to lack of needed info.