|
From: | Eric M. Ludlam |
Subject: | Re: Project systems (again) |
Date: | Sat, 19 Apr 2014 15:37:18 -0400 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.3a1pre) Gecko/20091222 Shredder/3.1a1pre |
On 04/19/2014 10:26 AM, Stefan Monnier wrote:
When support for projects of that nature were added, what I quickly found was that walking up the directory tree searching for them really hammered the auto-mounter on networked file systems.Currently, we walk up the tree several times per find-file for VC's backend detection. So this is a "solved" problem (use locate-dominating-file, which should really be named locate-dominating-dir, but it's not worth the trouble renaming it).
Thanks Stefan,I'd only heard of this function recently, and was unsure if it was appropriate for EDE. In particular, I see in reading the code that it tries to avoid searching for files around root, above home directories, and matching a particular regexp, so that is good.
I tried some timing tests with it in my CEDET repository (4 deep directory) looping 100 times to see how it competes.
Detect detect-with-ldf took 0.0166 seconds Detect detect-with-ldf-ede-simple took 0.0442 seconds Detect detect-with-ldf-ede-full took 0.2112 seconds Detect detect-with-ede took 0.0000 seconds Detect detect-with-ede-file-detect took 0.0016 seconds Detect detect-with-ede-no-buffer-cache took 0.1612 seconds Detect detect-with-ede-buffer-init-hook took 0.2805 seconds See attached code for details. It did pretty well considering the added feature.There are some strange hacks in the EDE autoloader due to not navigating up a directory tree. I'll see if I can take advantage of this function and simplify & enhance some of EDE's detection: the last 2 above timings.
Eric
tpdm.el
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |