ericdanan/counsel-projectile

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.