Comments
-
Greg Hurrell
I've pasted this in here to track the feature request for caching.
As to your second question, you can pass in a directory: eg.
:CommandT some/directory
-
lukasz
Created
,
edited
My project is over 15 000 files.
Problems:
- First run is about 10 sec.
- After typing first 3 characters - waiting for search about 5 sec. Every time. Next characters go faster of course. But imagine you make mistake and have to backspace this first chars.
- Not all diretories (on the first level) are scaned (or at least searchable).
my setting: let g:CommandTMaxFiles=100000
For example if i run vim in root directory of my project, and run
:CommandT
it doesn't see any file in IDX directory.
If i run
:CommandT IDX
every thing is OK.
-- lukasz
-
Greg Hurrell
There is no quick and easy fix for the performance degradation, I'm afraid. The first run is slow because it has to traverse the entire directory hierarchy, in Ruby. The initial slowness as it narrows down the list may just be because the number of files you're dealing with is too much for your machine (ie. perhaps enough to push some of the working set out of the processor cache).
As for the third issue, perhaps your Vim
'wildignore'
setting is responsible for excluding that directory. Or perhaps you have more files than you think? I'm pretty confident there are no bugs which would cause Command-T to overlook an entire directory hierarchy. -
lukasz
$ ls -R . | wc -l 13611
: set wildignore wildignore=
We must do it something with performance - cannot work without this plugin ;).
For now I use:
:CommandT dir
Maybe it will be a temporary solution to create new leader shortcut eg.: \y direcotry search_string
In that case it will first switch to "direcotry" like :CommandT dir (just after pressing space after the first word), and then perform normal search with "search_string".
-
Greg Hurrell
See also feature request #1878. That one adds the ability to use multiple caches, keyed off of directory names, so you could use
:CommandT dir
to limit the scope to a particular directory, but still get the benefit of the cache. -
Greg Hurrell
Closed this topic ("Slow startup in large project") as a duplicate of this ticket.
-
JKkim
Hello I just moved command-t from fuzzy-finder and I really satisfied with this plugin. however nowadays I am working in Android. Android project has over 100,000 files. therefore I need the feature that original poster asked. It would be nice, great if command-t can reopen the cache when I re-run the vim. For this functionality, cache could be file by options and could be select from cache-list window, when I want to re-open the cache. I grant that Command-T is still great and would be more great if it gives above functions. please........... In fact, I re-compiled the VIM only for using command-t in Cygwin. plz from JK. seoul korea
-
dtb
Hey folks, I'm working on a patch to cache the directory listing to disk on first run, so that you can avoid the startup delay. Subsequent runs would use the cache.
I've got a first pass of this over on a branch of my fork of Command-T. I'm going to try it out a bit, and once everything is looking good, I'll send a pull request.
-
anonymous
I am working on a mounted ssh file system and it's very slow every time to generate the cache. I will try your implementation JKkim
-
dtb
I added a pull request for this feature.
If anyone wants to try it out, just go to my fork, then follow the instructions to install the plugin. After you do that, go into the install directory, and do a
git checkout cache-paths-to-disk
Then, be sure to edit your vimrc to enable the cache:
let g:CommandTCacheIndexToDisk=1
Add a comment
Comments are now closed for this issue.