Re: Too long completion delay time in LISP interaction mode.

[Hongyi Zhao <hongyi.zhao@gmail.com>]

On Wed, Oct 20, 2021 at 1:58 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> First, I'd try to isolate where the slowdown happens.  The
> >> screenshots suggests you are using company-mode with custom hacks to
> >> get the numbering of candidates and you are using some fuzzy
> >> completion-style.
> >>
> >> So I'd start with emacs -Q and typing (map<TAB> in *scratch* to get
> >> the *Completions* buffer.  That will probably be fast but deliver
> >> less results because of the default value of `completion-styles'.
> >> Then I'd try out your settings of `completion-styles' (and
> >
> > `C-h o completion-styles RET'
> >
> > completion-styles is a variable defined in ‘minibuffer.el’.
> >
> > Its value is (hotfuzz)
>
> Never heard of it.

See here:

https://github.com/axelf4/hotfuzz

> But is it a suitable catch-all completion style,
> i.e., suitable for using it without another more prefix-oriented style
> preceeding it?  FWIW, when I type "(map", I'm most probably not
> interested in having smartparens-mode, or
> lsp:document-symbol-capabilities-hierarchical-document-symbol-support?
> showing up as the top candidates but more in mapcar, mapc, mapcan, you
> name it...

Agree with you.

> >> Also, using the profiler might shed some light on where the time is
> >> spent, see (info "(elisp) Profiling").
> >
> > `M-x profiler-start RET cpu and mem RET'
>
> I think you only need cpu here.

Thank you for pointing this out.

> > Typeset (map) in scratch buffer, and then
> >
> > `M-x profiler-report RET', gives the following results:
> >
> >    262,542,852  87% - command-execute
> >     262,542,852  87%  - funcall-interactively
> >     262,538,196  87%   - counsel-M-x
> >     262,538,196  87%    - let
> >     262,355,940  87%     - ivy-read
> >     262,355,940  87%      - apply
> >     262,354,884  87%       + #<lambda 0x1b9d5ef2eb92a3f2>
> >         182,256   0%     + counsel--M-x-externs
>
> So the bottleneck is in the lambda which you didn't expand.

I disabled hotfuzz now, and the following result is obtained by
profiling the CPU with the same steps as described above:

         472  88% - command-execute
         472  88%  - funcall-interactively
         472  88%   - counsel-M-x
         472  88%    - let
         448  84%     - ivy-read
         448  84%      - apply
         444  83%       + #<lambda 0x1b03f67daa2b12f2>
           4   0%       + my/company--transform-candidates
          24   4%     + counsel--M-x-externs
          45   8% + ...
          15   2% + redisplay_internal (C function)


> But I'm also not sure if you are profiling the right thing because I don't think
> that in-buffer completion (in terms of `completion-at-point-functions')
> starts with M-x (or counsel-M-x).

I'm not sure if it's relevant to the following configuration in my
`~/.emacs.d/init.el':

(use-package counsel
  :diminish counsel-mode
  :after helpful
  :init (setq ivy-use-selectable-prompt t
              search-default-mode #'char-fold-to-regexp
              counsel-describe-function-function #'helpful-callable
              counsel-describe-variable-function #'helpful-variable)
  :bind (("M-x" . counsel-M-x)
     ;; https://github.com/alpha2phi/dotfiles/blob/7c8c2c1ac9cf1cf95d60323f49c19545cfcef555/config/emacs/elisp/completion.el#L21
     ;; ("C-x C-f" . counsel-fzf)
         ("C-x C-f" . counsel-find-file)
     ;;https://github.com/abo-abo/swiper/issues/2888#issuecomment-874893794
         ("C-x 8 RET" . counsel-unicode-char)
         ("<f4>" . counsel-bookmark)
         ("s-4" . counsel-bookmark)
         ("s-r" . counsel-recentf))
  :config (counsel-mode 1)
  (defalias 'recent 'counsel-recentf))
(define-key minibuffer-local-map (kbd "C-r") 'counsel-minibuffer-history)

HZ