Why is the perfomance 3-5x times slower compared to stock :Files command?

[madnight]

Note that i superchared fzf with ripgrep https://medium.com/@crashybang/supercharge-vim-with-fzf-and-ripgrep-d4661fc853d2

[tweekmonster]

You can see why in the bash script: https://github.com/tweekmonster/fzf-filemru/blob/master/bin/filemru.sh

The project files are filtered from the start, so you will see a startup delay. I doubt that rg would matter since this isn't used for searching file contents. The pre-filtering is needed because the files must be sorted before they get to FZF. The MRU file list also needs to be validated so missing files aren't displayed. Additionally, git repos are handled a bit differently: git-ignored files are ignored (unless they're actually a MRU file), and submodules are completely ignored because they tend to add noise and add near-duplicate file matches that are not useful. All of this happens before we even get to the part where FZF presents the choices to you, so it's naturally going to be slower than simply enumerating files on the disk.

If you're on macOS and use /usr/bin/git (built in), chances are that it's a lot slower than the one provided by Homebrew. So, this could be another contributing factor.

This plugin's only performance-related goal was to be faster than a pure VimScript implementation of the above features.

[madnight]

Im on arch linux, thx for your very detailed answer, i added more filetypes and folders to ignore and the performance is now quiet aceptable. So i guess only a rewrite in go, rust, c ... could speed up the perf.

[tweekmonster]

So i guess only a rewrite in go, rust, c ... could speed up the perf.

Vim plugins that require a binary component require more maintenance and documentation, so I avoided it. I thought about using Go because it would've made it easy to have Windows support, though. But, this is a small plugin and there isn't exactly demand for that.

I think having a binary would speed up the string operations and the sorting, but I think the bottleneck is still going to be the git commands being ran in a subshell. Parsing .gitignore and .gitmodules could avoid calling git. This all requires effort just to find out if it's even beneficial and I'm not bothered enough by the performance to mess with it.

[madnight]

alright i think max. 3-5x times slower is fair enough under this conditions atm : )