Hacker News Reader

Comment by ghost91 | Hacker News Reader

Is also quite good.

It would cool to have a performance comparison

As a quick and dirty test I tried running both Command-T and Ctrl-P against a directory tree containing some 26,000 XML files. Command-T takes roughly 10-15 seconds to become responsive. Ctrl-P chokes and requires a Vim restart after invoking it against this directory.

That should be a fairly trivial fix in both of them.

Simply abort the scanning after a configurable threshold (either seconds or files).

Needless to say that, yes, this must be implemented.

I've choked my vim more than once by accidentally running Command-T or FuzzyFinder in the "wrong" directory. That should not happen.

Command-T definitely has the feature you're talking about (CommandTMaxFiles I think.) I'm not sure about CtrlP.

If you are on Unix, add this to your vimrc and the directory indexing speed should go through the roof:

https://gist.github.com/ee14d6ecb9196a07da56

Is that offloading the task of scanning file names to the find command?

Looks like find is piped into head, though. So it would only index the first ten?

No, it's the first g:ctrlp_max_files which is defined as 10000

Oh, true. Good call.

Is there a reason that Ctrl-P, FuzzyFinder, and Command-T choke on large directories? On windows, I've used this piece of software called Everything Search that seems to index the entire filesystem (say around 30,000 files) in under 5 seconds. That's really impressive and I love using it for that.

But it makes me sad to use these vim extensions choking on directories of similar size. Maybe NTFS vs ext4 has something to do with it?

I was never able to get Command-T to work. CtrlP works out of the box without extra work.

The main thing that attracted me to Ctrl-p was that it is written in pure vimscript. Command-T, however, requires your vim to be compiled with Ruby support.

In the projects I have worked on, Ctrl-P seems faster than Command-T, but it's matching results are far from a replacement for Command-T. Ctrl-P often will not find files even when I type out the full file name. Command-T's match results are great. Ctrl-P will also show results from hidden/ignored directories. When Ctrl-P is smarter about its match results, I will use it more frequently.

The overall comparison ends up being: Command-T is more of a pain to get setup, but is faster. CtrlP is easier to get setup, but is slower.

I'm also interested in knowing how fast this is with huge directory trees.

I remember in early versions of Command-T, the Ruby implementation was slow for big trees. They rewrote some of it later in C.

I just overheard Wincent say that Command-T was always written in C because previous Ruby plugins that attempted to accomplish the same thing was too slow. Command-T was written to be instant.

FWIW I ran

    cd
    vim
    <Ctrl+P>
    (wait 10~15s for it to complete)
    <ESC>
    :q
    find . |wc -l
    183239

Fast enough for me. (MacBookPro5,5 + aftermarket Samsung 470 SSD)

Command-T is faster for sure. But it lacks critical features that Ctrl-P has (no vim -ruby dependency for one).

When you start vim again and hit ctrl+p, does it do all that over again?

If I don't quit vim, and do Ctrl+P, things got cached (which you force-refresh with F5) so it's instant.

If I quit and restart vim, the Ctrl-P cache is invalidated thus it's scanning again, but it's down to 3~5s since disk reads got cached by the OS.

Yes. But you can specify a local cache file if you want... in which case it would not start over when you restart.

Ah, I see. I added a similar feature to Command-T, because scanning one of my projects trees takes a couple seconds.

Reply on news.ycombinator.com