From: Ben Wing <ben(a)666.com&gt; Date: Tue, 12 Jun 2001 01:04:16 -0700 please check out the newest etags.el. i did some synching with fsf in this area. FWIW, I just upgraded to 21.4.3 (more or less painlessly). 21.4.3 seems zippier and snazzier than 21.1.13, with the exception of tags lookup. Tag lookup is way slower for me, borderline annoying. I have tags-build-completion-table turned off. But I don't think that is causing the problem. 21.1.13 found 'find-tag' instantly, 21.4.3 took 10-15 seconds to find the same tag and using the same tag tables. -jeff Anthony wrote:

From: Vin Shelton <acs(a)xemacs.org&gt; Date: 12 Jun 2001 21:59:39 -0400 Jeff Mincy <jeff(a)delphioutpost.com&gt; writes: BTW, in 21.1.13, I did find-tag on S\+3 (from ESS), and found the real definition on the third try. 1) (defvar S+elsewhere-dialect-name "S+3" 2) (defvar S+3-dialect-name "S+3" 3) (defun S+3 (&optional proc-name) Whereas 21.4.3 finds the S+3 definition on the first try. So, it's better at finding the right tag, but lots slower. Snazzier certainly. Zippier I find very hard to believe. There have been numerous complaints about fontifying and about cc-mode. I think the startup code is probably slower in 21.4 also. Can you tell me what you think is faster and tell me what your platform is and what your configuration options are? What feels zippier is just moving around in the code. Perhaps. Well, I have a theory. It seems that lazy lock got turned off in 21.4 and the fontification happened when the file was loaded (and thus the new snazzy progress bar). Because of that, moving around probably was faster because it didn't need to do the lazy font stuff. I changed my init file to use (turn-on-lazy-lock) instead of the (remove-hook 'font-lock-mode-hook 'turn-on-fast-lock) (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock) Which had been handed down from the custom file from many releases ago. I haven't used cc enough lately to notice any issues. -jeff

Ben Wing <ben(a)666.com&gt; writes: fwiw, one *major* speed killer for me is uniquify. took me some time to find out what makes loading files so slow. -- The only complaint I have against WinDoze is that it doesn't always fail at install time. -- Mike Andrews, in s.d.m

Valdis.Kletnieks(a)vt.edu writes: which was (require 'uniquify). sorry for not writing clearly. [ as I said, "fwiw". sometimes the things that turn out to cause performance problems can be very inconspicuous. so you write a report about, say, version control getting extremely slow in the new XEmacs version, and then you find out that you added "(require 'uniquify)" to your .emacs as part of the obligatory after-upgrade review and *that* was the reason for the slowdown. almost happened to me. ] -- You shouldn't anthropomorphize computers; they don't like it.

Raymond Toy <toy(a)rtp.ericsson.se&gt; writes: oh, just lots of files with similar names. the slowness really kicks in when I'm working with several ClearCase views simultaneously and open same files in 2 or 3 different views. maybe my uniquify settings are to blame somehow: (setq uniquify-buffer-name-style 'post-forward) (setq uniquify-after-kill-buffer-p nil) ; disabled because having ; to wait 3 seconds for a ; buffer to close is ; especially frustrating -- There are many intelligent species in the universe. They are all owned by cats.

From: Ben Wing <ben(a)666.com&gt; Date: Tue, 12 Jun 2001 21:56:50 -0700 Jeff Mincy wrote: well, there you have it -- the only major change was the code integration i just mentioned, and things got slower. :-] but 10-15 seconds?? are you sure this isn't a font-lock problem? i use 21.5 for development and i have error-checking turned on and no optimization -- and i still see <1 second for find-tag. this is on a pentium III 700mhz. is this 10-15 seconds only the first find-tag, or all of them? Well, no, I'm not sure, maybe it is both font-lock and tag. find-tag is definitly slower, but now it takes more like 4-5 seconds. I think the rest of the time was fontifying. I'm on a 450mhz. -jeff

From: Ben Wing <ben(a)666.com&gt; Date: Wed, 13 Jun 2001 17:33:33 -0700 Jeff Mincy wrote: could you try starting up `xemacs -vanilla' and then running find-tag? [you might have to manually run some lines in your init file that set up the tag vars.] also, in your normal setup, try find-tag multiple times on the same tag. then try on multiple tags into the same file. you should definitely see <1 second on 450mhz unless you're seriously memory-strapped or working over a slow network. Ok. I did alias xemacs4="C:/PROGRA~1/XEmacs/XEmacs-21.4.3/i586-pc-win32/xemacs.exe" mv ~/.emacs ~/.emacs.foo mv ~/.xemacs ~/.xemacs.foo mv site-packages site-packages.foo - autoloads are still being run from cygwin bash: xemacs4 -vanilla in xemacs, I evaled the following (progn (defun tagdir (tags) (concat "c:/home/jmincy/tag/" tags)) (setq-default tags-build-completion-table nil) (setq-default tags-auto-read-changed-tag-files t) (setq-default make-tags-files-invisible t) (setq-default tag-table-alist (delete-if-not #'(lambda (x) (file-exists-p (cdr x))) `(("\\.e\\(l\\|macs\\)\\'" . ,(tagdir "XEMACS_TAGS")) ("\\.e\\(l\\|macs\\)\\'" . ,(tagdir "XEMACS_CTAGS")) ("\\.[RS]\\'" . ,(tagdir "S_TAGS")) ("\\.\\(cc?\\|hh?\\)\\'" . ,(tagdir "CTAGS")) ("xemacs-[0-9.]+/src/[^.]\\.[ch]\\'" . ,(tagdir "XEMACS_CTAGS")) ("\\.tcl\\'" . ,(tagdir "TCL_TAGS"))))) ) Then I do M-. find-tag. Which consistently takes 4-5 seconds. Maybe it is a little faster if etags.el is already loaded, but not much. The file wasn't fontified, so font-lock doesn't seem to be involved. Then I tried M-. ess-listing-minor-mode. This was instant. ess-listing-minor-mode is on line 198 of XEMACS_TAGS find-tag is on line 61356 (of 65718) of XEMACS_TAGS. So I went to line 20000 of XEMACS_TAGS and M-. that symbol (bookmark-bmenu-delete-backwards). That took about 2 seconds. Sounds linear in # tags, with a much higher multiplier. Off hand, I'd say that my system can search through 10000 tags per second in 21.4.3, which seems 5-10 times slower than 21.1.13. -jeff

Hrvoje> Vin Shelton <acs(a)xemacs.org&gt; writes: Hrvoje> Many aspects of XEmacs have been optimized, most notably Hrvoje> the Lisp engine. I don't think much of XEmacs is Lisp-bound, from the user's perspective. At least, I've done a little bit of random profiling recently, and many of the time synchs seem to be in primitives that have no business being slow. I'll try to get systematic about it in the next few weeks, but that's my current impression. Hrvoje> Startup could be slower, Not perceptibly for xemacs -vanilla for me. Hrvoje> and all syntax-related stuff has slowed down due to the Hrvoje> syntax changes. Yup -- any fontification in the startup (eg, if you use desktop.el) really slows things down. The progress bar is a great time-waster, knocking it down to small size helps a lot (though I don't know why), and disabling it is a big startup win for me (I rarely notice it in ordinary operation). All very subjective and YMMV. I do think these subjective perceptions of slowdown and some more precise reports (I think Quotemstr gave us a good one) need invesitgation before 21.4 is ready for prime time. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."