Performance of counsel-projectile-find-file
sefeng211 opened this issue · 14 comments
Hi, using counsel-projectile-find-file
on a large project (Firefox codebase in my case) is very janky and slow.
After typing the first few letters, the entire emacs process would hang for about 5-6 seconds before having the result listed.
Hi, is projectile-find-file
faster than counsel-projectile-find-file
? If so then there could a performance issue with the counsel-projectile. Otherwise the solution if any would rather be in projectile.
Yeah, I used native cache for projectile-find-file
and it's much faster.
I'm not sure I understand. Do you mean you set projectile-indexing-method
to native
? Or projectile-enable-caching
to t
? And is projectile-find-file
faster than counsel-projectile-find-file
then?
I set projectile-indexing-method
to native to gain better performance for projectile-find-file
. Since then, projectile-find-file
is much faster than counsel-projectile-find-file
.
There seems to be something to investigate in counsel-projectile then. Do you have projectile-enable-caching
set to t
? What completion does projectile use (projectile-completion-system
)? Can you try setting counsel-projectile-find-file-matcher
to nil
and calling counsel-projectile-find-file
?
Sorry for the late reply.
I don't have projectile-enable-caching
set to t
, it's nil
.
projectile-completion-system
says ivy
I am unable to set counsel-projectile-find-file-matcher
to nil
because emacs returns Value nil does not match type choice of counsel-projectile-find-file-matter
Sorry, you indeed cannot set counsel-projectile-find-file-matcher
to nil
, I meant set it to 'ivy--re-filter
(the default ivy matcher, so that should give the same performance as projectile-find-file
. Also is counsel-projectile-sort-files
at its default nil
value?
Setting projectile-enable-caching
to t
should increase performance, especially for large projects, but that should affect projectile-find-file
and counsel-projectile-find-file
equally.
Hello,
Are you still affected by this issue? I just downloaded the firefox
source code from https://github.com/mozilla/gecko-dev and projectile-find-file
and counsel-projectile-find-file
perform similarly for me: about 12s when projectile-enable-caching
is nil
and almost instantly once cached when t
.
Hi!
Yeah, I still have the same issue. I've set projectile-enable-caching
to t
, but projectile-find-file
still outperforms counsel-projectile-find-file
significantly.
Can you try setting counsel-projectile-find-file-matcher
to 'ivy--re-filter
(the default ivy matcher,
so that should give the same performance as projectile-find-file
) and making sure counsel-projectile-sort-files
is at its default nil
value?
So that indeed boosts the performance of counsel-projectile-sort-files
, however, I still feel projectile-find-file
performs better here..
OK let's try to measure the difference. Can you open a buffer from the project (say Makefile.in
) then evaluate each of these two forms from the scratch buffer with C-j
, press Enter
as soon as you see candidates in the minibuffer, and report the respective times?
(with-current-buffer "Makefile.in"
(benchmark-run 1
(projectile-invalidate-cache nil)
(projectile-find-file)))
(with-current-buffer "Makefile.in"
(benchmark-run 1
(let ((counsel-projectile-sort-files nil)
(counsel-projectile-find-file-matcher #'ivy--re-filter))
(projectile-invalidate-cache nil)
(counsel-projectile-find-file))))
Sorry, I don't use Emacs anymore and I don't think I'll provide more inputs here. So I am closing this.
Appreciate for help!
FYI @ericdanan I also experienced this issue on one of our projects (110k files) and setting 'ivy--re-filter
resolved the problem for me.