Improving find file performance by hacking in FindFileInProject. #21
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The change I made to FindFileInProject: use textmate.el's project root finder.
And picking between the find command and git ls-files if the active file happens
to be under git control.
The speed to first finding a file is significantly faster.
Here are the performance results that influenced my decision to list files under git control using
git ls-files
but avoid usinghg manifest
for mercurial (hardly scientific):With the django project I had the following timing results for listing files:
time find . -path *.hg -prune -o -name *.git -prune -o -print 1>/dev/null
real 0m0.111s
user 0m0.046s
sys 0m0.062s
time git ls-files 1>/dev/null
real 0m0.014s
user 0m0.009s
sys 0m0.004s
time hg manifest 1>/dev/null
real 0m0.406s
user 0m0.146s
sys 0m0.055s