4 ms·

The author mentioned CtrlP for fuzzy filename matching. Its great because it's in pure Vimscript, but in my experience it becomes unusably slow for moderately s

by derwiki 14y ago

The author mentioned CtrlP for fuzzy filename matching. Its great because it's in pure Vimscript, but in my experience it becomes unusably slow for moderately sized projects. A month or two ago, I switched back to CommandT (requires Vim to be compiled with Ruby support, engine written in C) and haven't thought twice about it since then.

oacgnol 14y ago
I've been meaning to try out matcher[0] for usage with CtrlP, I'm not sure how well it works but it's written in C and is purported to speed up search. Not sure if it's still being maintained, however... [0] https://github.com/burke/matcher https://github.com/burke/matcher
- burke 14y ago
  There's not much to maintain. I ported the matcher from Command-T out of its ruby-C wrapper, and it more or less just works. I use it dozens or hundreds of times a day.
- swift 14y ago
  It works quite well. The only negative I've found is that using matcher seems to disable CtrlP's usual highlighting of which letters in a search result are matched. In the end, though, I went back to Command-T.
statico 14y ago
How large is "moderately sized" ?
deleted 14y ago
[deleted]
bti 14y ago
I use CommandT primarily on my main machine but I also have CtrlP installed and they are both mapped to the same key (<leader>f) in a conditional. If I'm on a machine that has Vim compiled with Ruby, I get CommandT, otherwise CtrlP. Best of both worlds.
pieceofpeace 14y ago
I have a repo with 3000+ files and I can't notice any delay searching with CtrlP. I have the following custom file listing command in my vimrc: let g:ctrlp_user_command = { \ 'types': { \ 1: ['.git/', 'cd %s && git ls-files'], \ 2: ['.hg/', 'hg --cwd %s locate -I .'], \ }, \ 'fallback': 'find %s -type f' \ }
- mmahemoff 14y ago
  It's fine with many files, the only issue is when it indexes, which can't easily be automated. I just checked and it gets through about 2000 files a second on my MBP.
- atjoslin 14y ago
  Just made my CtrlP use ag[1], it's awesome now :-) let g:ctrlp_user_command = 'ag --nogroup --nobreak --noheading --nocolor -g "" %s ' [1] https://github.com/ggreer/the_silver_searcher https://github.com/ggreer/the_silver_searcher
ethereal 14y ago
I've found that my impression of CtrlP's speed varies dramatically depending on the project that I'm working on. For projects such as Bochs [0] (~750 files in CtrlP), I get annoyed at the initial .5-sec wait [1], but after that it's extremely fast. I don't have a particularly fast processor, either. I find CtrlP breaks down with large projects such as the Linux kernel. While it's fast to find the initial list of files (2 seconds or so) it's extremely slow to actually search through said list, about .5-sec per keystroke. [0] I'm not a maintainer, I just happen to be using its wonderful instrumentation hooks in a research project. [1] It's about half a second on my laptop, which has an SSD. This time is dramatically larger if you have a rotary drive, more like 10-20 seconds IIRC.
slurgfest 14y ago
You won't see the 'indexing' as much if you keep indexes between runs of vim: let g:ctrlp_clear_cache_on_exit=0

by derwiki 14y ago

oacgnol 14y ago

I've been meaning to try out matcher[0] for usage with CtrlP, I'm not sure how well it works but it's written in C and is purported to speed up search. Not sure if it's still being maintained, however... [0] https://github.com/burke/matcher https://github.com/burke/matcher

burke 14y ago
There's not much to maintain. I ported the matcher from Command-T out of its ruby-C wrapper, and it more or less just works. I use it dozens or hundreds of times a day.
swift 14y ago
It works quite well. The only negative I've found is that using matcher seems to disable CtrlP's usual highlighting of which letters in a search result are matched. In the end, though, I went back to Command-T.

statico 14y ago

How large is "moderately sized" ?

deleted 14y ago

[deleted]

bti 14y ago

I use CommandT primarily on my main machine but I also have CtrlP installed and they are both mapped to the same key (<leader>f) in a conditional. If I'm on a machine that has Vim compiled with Ruby, I get CommandT, otherwise CtrlP. Best of both worlds.

pieceofpeace 14y ago

I have a repo with 3000+ files and I can't notice any delay searching with CtrlP. I have the following custom file listing command in my vimrc: let g:ctrlp_user_command = { \ 'types': { \ 1: ['.git/', 'cd %s && git ls-files'], \ 2: ['.hg/', 'hg --cwd %s locate -I .'], \ }, \ 'fallback': 'find %s -type f' \ }

mmahemoff 14y ago
It's fine with many files, the only issue is when it indexes, which can't easily be automated. I just checked and it gets through about 2000 files a second on my MBP.
atjoslin 14y ago
Just made my CtrlP use ag[1], it's awesome now :-) let g:ctrlp_user_command = 'ag --nogroup --nobreak --noheading --nocolor -g "" %s ' [1] https://github.com/ggreer/the_silver_searcher https://github.com/ggreer/the_silver_searcher

ethereal 14y ago

I've found that my impression of CtrlP's speed varies dramatically depending on the project that I'm working on. For projects such as Bochs [0] (~750 files in CtrlP), I get annoyed at the initial .5-sec wait [1], but after that it's extremely fast. I don't have a particularly fast processor, either. I find CtrlP breaks down with large projects such as the Linux kernel. While it's fast to find the initial list of files (2 seconds or so) it's extremely slow to actually search through said list, about .5-sec per keystroke. [0] I'm not a maintainer, I just happen to be using its wonderful instrumentation hooks in a research project. [1] It's about half a second on my laptop, which has an SSD. This time is dramatically larger if you have a rotary drive, more like 10-20 seconds IIRC.

slurgfest 14y ago

You won't see the 'indexing' as much if you keep indexes between runs of vim: let g:ctrlp_clear_cache_on_exit=0