5 ms·
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
by 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 agoI 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 agoFWIW 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 agoWhen you start vim again and hit ctrl+p, does it do all that over again?
- lloeki 14y agoIf 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 agoYes. But you can specify a local cache file if you want... in which case it would not start over when you restart.
- notJim 14y agoAh, I see. I added a similar feature to Command-T, because scanning one of my projects trees takes a couple seconds.