[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Files not under VC (e.g. ~/.newsrc) load/save excessively slow
|
From: |
Andrew M. Scott |
|
Subject: |
Files not under VC (e.g. ~/.newsrc) load/save excessively slow |
|
Date: |
Fri, 22 Jul 2005 13:46:38 -0700 |
Visiting files *not* under VC (e.g. ~/.newsrc) are taking
15-20 seconds to load in CVS Emacs; this slowness is not seen in
Emacs-21.3 or in files registered in RCS or CVS on the same system.
I am also seeing excessive save time for the ~/.newsrc file from gnus.
The slowness appears to be in the VC code for arch and MCVS/CVS. The
directory system for this file is nfs on a gnu/linux system.
DETAILS
/eng/eng10/ascott/.newsrc == ~/.newsrc is not under any VC system and takes
18 seconds to load in a 7/22/2005 build of CVS Emacs.
1. Using debug-on-quit on the .newsrc example gave the following *Backtrace*
Debugger entered--Lisp error: (quit)
vc-find-root("/eng/eng10/ascott/.newsrc" "{arch}/=tagging-method")
(if (vc-find-root file "{arch}/=tagging-method") (progn (load "vc-arch")
(vc-arch-registered file)))
vc-arch-registered("/eng/eng10/ascott/.newsrc")
apply(vc-arch-registered "/eng/eng10/ascott/.newsrc")
vc-call-backend(Arch registered "/eng/eng10/ascott/.newsrc")
#[(b) "=8c2=8c3 #=85
mapcar(#[(b) "=8c2=8c3 #=85
byte-code("=8c3=8c4\"=8c5=8c6 =83
vc-registered("/eng/eng10/ascott/.newsrc")
vc-backend("/eng/eng10/ascott/.newsrc")
vc-before-save()
basic-save-buffer()
save-buffer()
gnus-gnus-to-newsrc-format()
gnus-save-newsrc-file()
gnus-group-exit()
call-interactively(gnus-group-exit)
2. Profiling:
M-x elp-instrument-package vc
(vc-registered "/eng/eng10/ascott/.newsrc") C-u C-x C-e
M-x elp-results
Function Name Call Count Elapsed Time Average Time
======================================== ========== ============ ============
vc-registered 2 18.516143 9.2580715
vc-call-backend 7 18.515890999 2.6451272857
vc-find-root 2 18.504849 9.2524245
vc-mcvs-registered 1 9.872197 9.872197
vc-arch-registered 1 8.632692 8.632692
vc-default-registered 3 0.007767 0.0025889999
vc-check-master-templates 3 0.0076639999 0.0025546666
vc-rcs-registered 2 0.005169 0.0025845
vc-sccs-registered 1 0.002628 0.002628
vc-cvs-registered 1 0.002079 0.002079
vc-svn-registered 1 0.000842 0.000842
vc-after-save 4 0.000405 0.00010125
vc-possible-master 7 0.000179 2.557...e-05
vc-before-save 4 0.000163 4.075e-05
vc-backend 8 0.0001429999 1.787...e-05
vc-find-backend-function 5 0.0001290000 2.580...e-05
vc-make-backend-sym 8 0.000101 1.2625e-05
vc-file-getprop 22 9.399...e-05 4.272...e-06
vc-state 8 6.6e-05 8.25e-06
vc-sccs-search-project-dir 1 2.4e-05 2.4e-05
vc-file-setprop 3 1.400...e-05 4.666...e-06
3. M-x debug-on-entry vc-registered
Ran C-u C-x C-e on the following
(vc-registered "/eng/eng10/ascott/.newsrc")
Stepping through the debugger, I could see vc-registered checking to see
if the file was registered for RCS, CVS, SVN, SCCS, arch, MCVS/CVS, etc.
The problem first manifests itself when you get to the arch code,
but also occurs on MCVS/CVS (data not shown here).
I noticed that the code appears to use vc-find-root to climb up the users
directory tree, e.g.
from /eng/eng10/ascott
to /eng/eng10
to /eng/
to /
The file-exists-p step for the arch VC mode was the first which was excessively
slow,
and produced the following *Backtrace*:
Debugger entered--returning value: nil
file-exists-p("/eng/{arch}/=tagging-method")
* vc-find-root("/eng/eng10/ascott/.newsrc" "{arch}/=tagging-method")
* (if (vc-find-root file "{arch}/=tagging-method") (progn (load "vc-arch")
(vc-arch-registered file)))
* vc-arch-registered("/eng/eng10/ascott/.newsrc")
* apply(vc-arch-registered "/eng/eng10/ascott/.newsrc")
* vc-call-backend(Arch registered "/eng/eng10/ascott/.newsrc")
* #[(b) "=8c2=8c3 #=85
* mapcar(#[(b) "=8c2=8c3 #=85
* byte-code("=8c3=8c4\"=8c5=8c6 =83
* byte-code("=8c3=8c4 =8c5\n!\"=83
* vc-registered("/eng/eng10/ascott/.newsrc")
eval((vc-registered "/eng/eng10/ascott/.newsrc"))
eval-last-sexp-1((4))
eval-last-sexp((4))
call-interactively(eval-last-sexp)
Similarly, the MCVS/CVS mode was was excessively slow for:
(file-exists-p "/eng/MCVS/CVS")
In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, X toolkit)
of 2005-07-22 on chlr4920
X server distributor `The XFree86 Project, Inc', version 11.0.40300000
configured using `configure '--prefix=/stor/garray/linux'
'--x-includes=/usr/intel/pkgs/X11/R6.7.0/include'
'--x-libraries=/usr/intel/pkgs/X11/R6.7.0/lib' 'CC=gcc' 'CFLAGS=-O2
-I/usr/intel/pkgs/X11/R6.7.0/include -L/usr/intel/pkgs/X11/R6.7.0/lib
-I/usr/intel/pkgs/zlib/1.2.1/include -L/usr/intel/pkgs/zlib/1.2.1/lib
-I/usr/intel/pkgs/ncurses/5.4/include -L/usr/intel/pkgs/ncurses/5.4/lib
-I/usr/intel/pkgs/libungif/4.1.3/include -L/usr/intel/pkgs/libungif/4.1.3/lib
-I/usr/intel/pkgs/libpng/1.0.16rc1/include
-L/usr/intel/pkgs/libpng/1.0.16rc1/lib -I/usr/intel/pkgs/jpeg/6b/include
-L/usr/intel/pkgs/jpeg/6b/lib' 'LDFLAGS=-L/usr/intel/pkgs/X11/R6.7.0/lib
-L/usr/intel/pkgs/zlib/1.2.1/lib -L/usr/intel/pkgs/ncurses/5.4/lib
-L/usr/intel/pkgs/libungif/4.1.3/lib -L/usr/intel/pkgs/libpng/1.0.16rc1/lib
-L/usr/intel/pkgs/jpeg/6b/lib
-Wl,-rpath=/usr/intel/pkgs/X11/R6.7.0/lib:/usr/intel/pkgs/zlib/1.2.1/lib:/usr/intel/pkgs/ncurses/5.4/lib:/usr/intel/pkgs/libungif/4.1.3/lib:/usr/intel/pkgs/libp!
ng/1.0.16rc1/lib:/usr/intel/pkgs/jpeg/6b/lib''
Important settings:
value of $LC_ALL: en_US
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: C
locale-coding-system: iso-latin-1
default-enable-multibyte-characters: t
Major mode: Text
Minor modes in effect:
tool-bar-mode: t
mouse-wheel-mode: t
tooltip-mode: t
auto-compression-mode: t
menu-bar-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
line-number-mode: t
next-error-follow-minor-mode: Fol
- Files not under VC (e.g. ~/.newsrc) load/save excessively slow,
Andrew M. Scott <=