Further VC tuning is blocked

Further VC tuning is blocked

[Eric S. Raymond]

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

Re: Further VC tuning is blocked

[Dan Nicolaescu]

"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?

Re: Further VC tuning is blocked

[Eric S. Raymond]

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>

Re: Further VC tuning is blocked

[Tom Tromey]

>>>>> "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

Re: Further VC tuning is blocked

[Tom Tromey]

>>>>> "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)