unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Hongyi Zhao <hongyi.zhao@gmail.com>
To: Tassilo Horn <tsdh@gnu.org>
Cc: help-gnu-emacs <help-gnu-emacs@gnu.org>
Subject: Re: Too long completion delay time in LISP interaction mode.
Date: Wed, 20 Oct 2021 14:24:58 +0800	[thread overview]
Message-ID: <CAGP6PO+37by96-cCRBsVDCN2SwvGbDHn8XGoQz8MKpv+1FkoBQ@mail.gmail.com> (raw)
In-Reply-To: <CAGP6POJP5YnzFfa2R6PjhgAGVNdBJ6kTzQVSVd7+pDjv7TKfGw@mail.gmail.com>

On Wed, Oct 20, 2021 at 2:11 PM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> 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)

`C-h o counsel-M-x RET' gives the following:

counsel-M-x is an interactive Lisp closure in ‘counsel.el’.

It is bound to <execute>, M-x.


So it is unnecessary to set the above key binding. And the profiling
results are as follows without this keybinding:


        3056  55% - command-execute
        3056  55%  - funcall-interactively
        1227  22%   - counsel-M-x
        1227  22%    - let
        1132  20%     - ivy-read
        1132  20%      - apply
        1132  20%       + #<lambda 0x1c18740442433ef2>
          95   1%     + counsel--M-x-externs
         989  18%   + next-line
         622  11%   + counsel-describe-symbol
         123   2%   + save-buffer
          46   0%   + recentf-open-most-recent-file-1
          30   0%     mwheel-scroll
          12   0%   + swiper
           6   0%   + kill-whole-line
           1   0%     #<compiled 0x12193bdf30bd6a1b>
        1357  24% + ...
         516   9% + redisplay_internal (C function)
         500   9% + timer-event-handler
          33   0% + substitute-command-keys

>      ;; 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



  parent reply	other threads:[~2021-10-20  6:24 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-20  3:11 Too long completion delay time in LISP interaction mode Hongyi Zhao
2021-10-20  4:11 ` Emanuel Berg via Users list for the GNU Emacs text editor
2021-10-20  4:27   ` Hongyi Zhao
2021-10-20  5:01 ` Tassilo Horn
2021-10-20  5:29   ` Hongyi Zhao
2021-10-20  5:49     ` Tassilo Horn
2021-10-20  6:11       ` Hongyi Zhao
2021-10-20  6:19         ` Tassilo Horn
2021-10-20  6:42           ` Hongyi Zhao
2021-10-20  7:20             ` Tassilo Horn
2021-10-20  7:35               ` Hongyi Zhao
2021-10-21  5:32               ` Hongyi Zhao
2021-10-21  5:45                 ` Tassilo Horn
2021-10-21  6:14                   ` Hongyi Zhao
2021-10-21  8:50                     ` Tassilo Horn
2021-10-21 10:38                       ` Hongyi Zhao
2021-10-20  7:24             ` Hongyi Zhao
2021-10-20  7:37               ` Tassilo Horn
2021-10-20  9:17                 ` Hongyi Zhao
2021-10-20  6:24         ` Hongyi Zhao [this message]
2021-10-20  5:58     ` Hongyi Zhao
2021-10-20 15:30       ` [External] : " Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGP6PO+37by96-cCRBsVDCN2SwvGbDHn8XGoQz8MKpv+1FkoBQ@mail.gmail.com \
    --to=hongyi.zhao@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=tsdh@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).