From: David De La Harpe Golden <david@harpegolden.net>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: acm@muc.de, Eli Zaretskii <eliz@gnu.org>,
Lennart Borgman <lennart.borgman@gmail.com>,
emacs-devel@gnu.org
Subject: Re: Emacs 23.0 is much slower starting than Emacs 22.3
Date: Sat, 25 Oct 2008 00:44:56 +0100 [thread overview]
Message-ID: <49025DF8.6030502@harpegolden.net> (raw)
In-Reply-To: <jwv4p3125vn.fsf-monnier+emacs@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]
Stefan Monnier wrote:
>
> Setting vc-handled-backends to nil should indeed stop VC from doing
> those directory walks. So now I don't understand why the walks done by
> VC are so much cheaper than the ones done by locate-dominating-file.
> Could it be that all the files you opened were under CVS control (so
> the VC search stops before having to walk up the directories)?
>
>
Eventually found vc-find-root. So - it versus locate-dominating-file ?
While they're doing a fairly similar job, they do look to me like
they're implemented importantly differently -locate-dominating-file
takes a regex and passes it to directory-files for each directory.
AFAICS directory-files scans the whole directory each time through for
the match. OTOH, vc-find-root just tests if /path/to/directory/witness
exists. The former is rather slower and (I think) consier. I'm not sure
that there's any real performance problem with directory-files itself
for what it actually does, though maybe it could be made faster. Maybe
not worthwhile though - easier to rewrite locate-dominating-file to not
use it as below...
Profiling says locate-dominating-file is spending most all its time in
directory-files trying that doomed match again and again...
find-file-noselect 1108 48.279532999 0.0435735857
find-file-noselect-1 1108 29.139766999 0.0262994287
after-find-file 1108 26.323623999 0.0237577833
normal-mode 1108 21.492128000 0.0193972274
hack-local-variables 1108 19.570003 0.0176624575
hack-project-variables 1108 19.266695999 0.0173887148
project-find-settings-file 1108 19.254854999 0.0173780279
locate-dominating-file 1108 19.237415000 0.0173622879
directory-files 4152 18.688168999 0.0045010040
So is locate-dominating-file's regex-matching really necessary in
project-find-settings-file? The only call to locate-dominating-file I
can see is it just searching for a (hardcoded name) ".dir.settings.el"
in project-find-settings-file, so vc-find-root's rather simpler witness
technique would work just fine?
+++ And indeed, attached patch makes emacs23 1108-file-startup rather
more competitive with emacs22 on my system. Though I didn't do much
testing to see if project settings functionality was 100% a-okay -
though it seemed to pick up a /usr/local/src/emacs-22.3/.dir-settings.el
I made okay...
emacs patch withsettings realtime
22 n/a n/a 22.853
23 no no 38.518
23 no yes 38.729
23 yes no 23.295
23 yes yes 23.340
[-- Attachment #2: emacs-faster-locate-dominating-file.diff --]
[-- Type: text/x-patch, Size: 4135 bytes --]
Index: lisp/files.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/files.el,v
retrieving revision 1.1005
diff -U 8 -r1.1005 files.el
--- lisp/files.el 18 Oct 2008 18:40:25 -0000 1.1005
+++ lisp/files.el 24 Oct 2008 23:37:19 -0000
@@ -711,18 +711,59 @@
(defun locate-file-completion (string path-and-suffixes action)
"Do completion for file names passed to `locate-file'.
PATH-AND-SUFFIXES is a pair of lists, (DIRECTORIES . SUFFIXES)."
(locate-file-completion-table (car path-and-suffixes)
(cdr path-and-suffixes)
string nil action))
(make-obsolete 'locate-file-completion 'locate-file-completion-table "23.1")
-(defun locate-dominating-file (file regexp)
- "Look up the directory hierarchy from FILE for a file matching REGEXP."
+(defun locate-dominating-file (file name)
+ "Look up the directory hierarchy from FILE for a file named NAME.
+If found, return the file named NAME's full name and path, otherwise
+return nil. See locate-dominating-file-by-regexp if you have more
+complex requirements than a simple whole-string match on the name,
+though beware it is slower."
+ ;; copied from vc-find-root, then changed to return file
+ ;; rather than containing dir.
+ ;; Represent /home/luser/foo as ~/foo so that we don't try to look for
+ ;; witnesses in /home or in /.
+ (setq file (abbreviate-file-name file))
+ (let ((root nil)
+ (prev-file file)
+ ;; `user' is not initialized outside the loop because
+ ;; `file' may not exist, so we may have to walk up part of the
+ ;; hierarchy before we find the "initial UID".
+ (user nil)
+ try)
+ (while (not (or root
+ (null file)
+ ;; As a heuristic, we stop looking up the hierarchy of
+ ;; directories as soon as we find a directory belonging
+ ;; to another user. This should save us from looking in
+ ;; things like /net and /afs. This assumes that all the
+ ;; files inside a project belong to the same user.
+ (let ((prev-user user))
+ (setq user (nth 2 (file-attributes file)))
+ (and prev-user (not (equal user prev-user))))
+ (string-match
+ ;; from vc-ignore-dir-regexp !
+ "\\`\\(?:[\\/][\\/]\\|/\\(?:net\\|afs\\|\\.\\.\\.\\)/\\)\\'"
+ file)))
+ (setq try (file-exists-p (expand-file-name name file)))
+ (cond (try (setq root file))
+ ((equal file (setq prev-file file
+ file (file-name-directory
+ (directory-file-name file))))
+ (setq file nil))))
+ (when root (expand-file-name name root))))
+
+(defun locate-dominating-file-by-regexp (file regexp)
+ "Look up the directory hierarchy from FILE for a file matching REGEXP.
+This function is slower than `locate-dominating-file', only use if necessary."
(catch 'found
;; `user' is not initialized yet because `file' may not exist, so we may
;; have to walk up part of the hierarchy before we find the "initial UID".
(let ((user nil)
;; Abbreviate, so as to stop when we cross ~/.
(dir (abbreviate-file-name (file-name-as-directory file)))
files)
(while (and dir
@@ -3154,17 +3195,17 @@
(defun project-find-settings-file (file)
"Find the settings file for FILE.
This searches upward in the directory tree.
If a settings file is found, the file name is returned.
If the file is in a registered project, a cons from
`project-directory-alist' is returned.
Otherwise this returns nil."
(setq file (expand-file-name file))
- (let* ((settings (locate-dominating-file file "\\`\\.dir-settings\\.el\\'"))
+ (let* ((settings (locate-dominating-file file ".dir-settings.el"))
(pda nil))
;; `locate-dominating-file' may have abbreviated the name.
(if settings (setq settings (expand-file-name settings)))
(dolist (x project-directory-alist)
(when (and (eq t (compare-strings file nil (length (car x))
(car x) nil nil))
(> (length (car x)) (length (car pda))))
(setq pda x)))
next prev parent reply other threads:[~2008-10-24 23:44 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 9:11 Emacs 23.0 is much slower starting than Emacs 22.3 Alan Mackenzie
2008-10-22 13:23 ` Stefan Monnier
2008-10-22 13:55 ` John covici
2008-10-22 15:14 ` Alan Mackenzie
2008-10-22 16:46 ` David De La Harpe Golden
2008-10-22 21:12 ` Alan Mackenzie
2008-10-22 21:19 ` Eli Zaretskii
2008-10-23 9:21 ` Alan Mackenzie
2008-10-23 21:53 ` Eli Zaretskii
2008-10-23 6:53 ` David De La Harpe Golden
2008-10-23 9:09 ` Alan Mackenzie
2008-10-23 16:57 ` David De La Harpe Golden
2008-10-23 21:52 ` Eli Zaretskii
2008-10-23 22:33 ` Lennart Borgman
2008-10-24 9:26 ` Eli Zaretskii
2008-10-23 22:47 ` David De La Harpe Golden
2008-10-23 23:12 ` Lennart Borgman
2008-10-23 23:54 ` Lennart Borgman
2008-10-24 9:51 ` Eli Zaretskii
2008-10-24 13:58 ` David De La Harpe Golden
2008-10-24 15:44 ` Lennart Borgman
2008-10-24 16:24 ` Chong Yidong
2008-10-24 16:48 ` Eli Zaretskii
2008-10-24 16:45 ` David De La Harpe Golden
2008-10-24 16:53 ` Eli Zaretskii
2008-10-25 2:01 ` Richard M. Stallman
2008-10-25 3:38 ` David De La Harpe Golden
2008-10-24 0:13 ` David De La Harpe Golden
2008-10-24 0:59 ` Lennart Borgman
2008-10-24 1:58 ` David De La Harpe Golden
2008-10-24 1:44 ` David De La Harpe Golden
2008-10-24 9:57 ` Eli Zaretskii
2008-10-24 15:00 ` David De La Harpe Golden
2008-10-24 11:21 ` Alan Mackenzie
2008-10-24 14:32 ` David De La Harpe Golden
2008-10-24 19:28 ` Alan Mackenzie
2008-10-24 19:35 ` David De La Harpe Golden
2008-10-24 4:13 ` Stefan Monnier
2008-10-24 15:19 ` David De La Harpe Golden
2008-10-24 18:42 ` Stefan Monnier
2008-10-24 19:36 ` David De La Harpe Golden
2008-10-24 23:44 ` David De La Harpe Golden [this message]
2008-10-25 15:19 ` Stefan Monnier
2008-10-25 17:02 ` David De La Harpe Golden
2008-10-24 9:52 ` Eli Zaretskii
2008-10-24 9:35 ` Eli Zaretskii
2008-10-24 9:30 ` Eli Zaretskii
2008-10-23 1:29 ` Miles Bader
2008-10-23 9:06 ` Alan Mackenzie
2008-10-22 18:26 ` Eli Zaretskii
2008-10-22 21:40 ` Alan Mackenzie
2008-10-22 22:09 ` Eli Zaretskii
2008-10-22 21:02 ` Richard M. Stallman
2008-10-24 11:59 ` Emacs 23.0 is much slower than Emacs 22.3. Maybe it's the garbage collector Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49025DF8.6030502@harpegolden.net \
--to=david@harpegolden.net \
--cc=acm@muc.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lennart.borgman@gmail.com \
--cc=monnier@IRO.UMontreal.CA \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).