* Further VC tuning is blocked @ 2008-01-04 13:17 Eric S. Raymond 2008-01-04 17:37 ` Dan Nicolaescu 2008-01-05 2:59 ` Tom Tromey 0 siblings, 2 replies; 5+ messages in thread From: Eric S. Raymond @ 2008-01-04 13:17 UTC (permalink / raw) To: emacs-devel I think I've reached the limit of what I can do to speed-tune VC, pending one of the following developments: 1. Profiling discloses another hotspot that I can micro-optimize away. 2. We drop Dired and go with something like ewoc. While I'm willing to do the latter, I'm fairly neutral on the design issue. I still want to hear RMS's arguments for retaiming Dired. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> "Guard with jealous attention the public liberty. Suspect every one who approaches that jewel. Unfortunately, nothing will preserve it but downright force. Whenever you give up that force, you are inevitably ruined." -- Patrick Henry, speech of June 5 1788 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Further VC tuning is blocked 2008-01-04 13:17 Further VC tuning is blocked Eric S. Raymond @ 2008-01-04 17:37 ` Dan Nicolaescu 2008-01-04 18:08 ` Eric S. Raymond 2008-01-05 2:59 ` Tom Tromey 1 sibling, 1 reply; 5+ messages in thread From: Dan Nicolaescu @ 2008-01-04 17:37 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel "Eric S. Raymond" <esr@snark.thyrsus.com> writes: > I think I've reached the limit of what I can do to speed-tune VC, > pending one of the following developments: > > 1. Profiling discloses another hotspot that I can micro-optimize away. Have you thought of porting some of the vc-dired fixes to the 22.2 branch? Is it feasible? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Further VC tuning is blocked 2008-01-04 17:37 ` Dan Nicolaescu @ 2008-01-04 18:08 ` Eric S. Raymond 0 siblings, 0 replies; 5+ messages in thread From: Eric S. Raymond @ 2008-01-04 18:08 UTC (permalink / raw) To: Dan Nicolaescu; +Cc: Eric S. Raymond, emacs-devel Dan Nicolaescu <dann@ics.uci.edu>: > Have you thought of porting some of the vc-dired fixes to the 22.2 > branch? Is it feasible? Probably not, alas. The central optimization requires some back-end changes. It's not that doing them would be hard, but verifying that they'd all been done consistently while preseving the old API would be nasty. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Further VC tuning is blocked 2008-01-04 13:17 Further VC tuning is blocked Eric S. Raymond 2008-01-04 17:37 ` Dan Nicolaescu @ 2008-01-05 2:59 ` Tom Tromey 2008-01-05 18:09 ` Tom Tromey 1 sibling, 1 reply; 5+ messages in thread From: Tom Tromey @ 2008-01-05 2:59 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel >>>>> "Eric" == Eric S Raymond <esr@snark.thyrsus.com> writes: Eric> I think I've reached the limit of what I can do to speed-tune VC, Eric> pending one of the following developments: I found one more thing I don't understand here. I tried this: (defadvice vc-svn-command (before lala-reg (buffer okstatus file-or-list &rest flags) activate) (message "running svn %s %s" file-or-list (apply 'concat flags))) Then I ran C-x v d on gcc. I see 16 separate execs of 'svn': running svn /home/tromey/gnu/Trunk/trunk/gcc/ status-v running svn nil status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/cscope.in.out status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/cscope.out status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/cscope.po.out status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/REVISION status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/TAGS status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/TAGS.sub status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/cp/TAGS status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/cp/TAGS.sub status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/fortran/TAGS status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/fortran/TAGS.sub status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/java/TAGS status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/java/TAGS.sub status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/objc/TAGS status-v running svn /home/tromey/gnu/Trunk/trunk/gcc/objc/TAGS.sub status-v Many of these files are actually ignored. Maybe running 'svn status -v --no-ignore' would be better. I hacked this in to vc-svn-dir-state, but to my surprise it didn't help. Second, note the second line of the trace. We are running 'svn status -v' twice on the whole tree, once with the directory name as an argument, and once with default-directory set (and no explicit argument). (FWIW the --no-ignore hack affected this second line in a subsequent test, but nothing else. So the other calls are not from vc-svn-dir-state -- you probably know this.) Anyway, I think there's still a bit of room for improvement here. I think it should be possible to invoke svn a single time for this particular scenario. Tom ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Further VC tuning is blocked 2008-01-05 2:59 ` Tom Tromey @ 2008-01-05 18:09 ` Tom Tromey 0 siblings, 0 replies; 5+ messages in thread From: Tom Tromey @ 2008-01-05 18:09 UTC (permalink / raw) To: Eric S. Raymond; +Cc: emacs-devel >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes: Tom> Anyway, I think there's still a bit of room for improvement here. I Tom> think it should be possible to invoke svn a single time for this Tom> particular scenario. This patch seems to achieve that. I didn't update the svn status call in vc-svn-registered. It doesn't seem needed. I removed a call to buffer-disable-undo, because it doesn't do anything and is just confusing -- temporary buffers have undo disabled by default. Unfortunately this barely speeds up my test case. It cut off 2 seconds, down to 318 :-(. Still, IMO it is worth applying. Tom 2008-01-05 Tom Tromey <tromey@redhat.com> * vc-svn.el (vc-svn-state): Pass --no-ignore to svn. (vc-svn-dir-state): Likewise. Remove call to buffer-disable-undo. *** vc-svn.el 02 Jan 2008 16:11:33 -0700 1.59 --- vc-svn.el 05 Jan 2008 10:48:23 -0700 *************** *** 1,6 **** ;;; vc-svn.el --- non-resident support for Subversion version-control ! ;; Copyright (C) 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc. ;; Author: FSF (see vc.el for full credits) ;; Maintainer: Stefan Monnier <monnier@gnu.org> --- 1,6 ---- ;;; vc-svn.el --- non-resident support for Subversion version-control ! ;; Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc. ;; Author: FSF (see vc.el for full credits) ;; Maintainer: Stefan Monnier <monnier@gnu.org> *************** *** 139,145 **** (setq localp (or localp (vc-stay-local-p file))) (with-temp-buffer (cd (file-name-directory file)) ! (vc-svn-command t 0 file "status" (if localp "-v" "-u")) (vc-svn-parse-status file))) (defun vc-svn-state-heuristic (file) --- 139,145 ---- (setq localp (or localp (vc-stay-local-p file))) (with-temp-buffer (cd (file-name-directory file)) ! (vc-svn-command t 0 file "status" (if localp "-v" "-u") "--no-ignore") (vc-svn-parse-status file))) (defun vc-svn-state-heuristic (file) *************** *** 153,160 **** ;; Don't specify DIR in this command, the default-directory is ;; enough. Otherwise it might fail with remote repositories. (with-temp-buffer ! (buffer-disable-undo) ;; Because these buffers can get huge ! (vc-svn-command t 0 nil "status" (if localp "-v" "-u")) (vc-svn-parse-status)))) (defun vc-svn-working-revision (file) --- 153,159 ---- ;; Don't specify DIR in this command, the default-directory is ;; enough. Otherwise it might fail with remote repositories. (with-temp-buffer ! (vc-svn-command t 0 nil "status" (if localp "-v" "-u") "--no-ignore") (vc-svn-parse-status)))) (defun vc-svn-working-revision (file) ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-01-05 18:09 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-01-04 13:17 Further VC tuning is blocked Eric S. Raymond 2008-01-04 17:37 ` Dan Nicolaescu 2008-01-04 18:08 ` Eric S. Raymond 2008-01-05 2:59 ` Tom Tromey 2008-01-05 18:09 ` Tom Tromey
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.