6 ms·

https://github.com/wincent/Command-T https://github.com/wincent/Command-T Is also quite good. It would cool to have a performance comparison

• roelbondoc 14y ago
  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.
• greyfade 14y ago
  I was never able to get Command-T to work. CtrlP works out of the box without extra work.
• idank 14y ago
  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.
  • derwiki 14y ago
    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.
  • lloeki 14y ago
    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).
    • notJim 14y ago
      When you start vim again and hit ctrl+p, does it do all that over again?
      • lloeki 14y ago
        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.
      • westcave 14y ago
        Yes. But you can specify a local cache file if you want... in which case it would not start over when you restart.
        • notJim 14y ago
          Ah, I see. I added a similar feature to Command-T, because scanning one of my projects trees takes a couple seconds.
• michael_michael 14y ago
  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.
  • moe 14y ago
    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.
    • notJim 14y ago
      Command-T definitely has the feature you're talking about (CommandTMaxFiles I think.) I'm not sure about CtrlP.
  • amadeus 14y ago
    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 https://gist.github.com/ee14d6ecb9196a07da56
    • jamesgeck0 14y ago
      Is that offloading the task of scanning file names to the find command?
      • jpk 14y ago
        Looks like find is piped into head, though. So it would only index the first ten?
        • aidenn0 14y ago
• Oompa 14y ago
  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.
• mrinterweb 14y ago
  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.