help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Hongyi Zhao
Subject: Re: Too long completion delay time in LISP interaction mode.
Date: Wed, 20 Oct 2021 13:58:56 +0800

On Wed, Oct 20, 2021 at 1:29 PM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> On Wed, Oct 20, 2021 at 1:08 PM Tassilo Horn <tsdh@gnu.org> wrote:
> >
> > Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> >
> > > On Ubuntu 20.04.3 LTS, I'm using the self compiled Emacs git master
> > > version. I find there is a very long completion delay time in LISP
> > > interaction mode. For example, when I type `(map)' in scratch buffer,
> > > there will have 5070 candidates as shown in the attached file, and the
> > > completion delay is about 2-5 seconds.
> > >
> > > Any hints to improve this phenomenon?
> >
> > 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)
> Original value was
> (basic partial-completion emacs22)

I've the following configuration in my `~/.emacs.d/init.el':


(use-package hotfuzz
  :init
  (setq completion-styles '(hotfuzz)))

And it seems that commented out the above code snippet fixed the
problem discussed here.

HZ

>
> > `completion-category-overrides' if you have customized that).
>
> `C-h o completion-category-overrides RET'
>
> completion-category-overrides is a variable defined in ‘minibuffer.el’.
>
> Its value is nil
>
>
> >  Then again with `company-mode' but first without the numbering hack, and
> > eventually with it.  At which step does it become slow?
> >
> > 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'
>
> 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
>           4,656   0%   + self-insert-command
>      36,160,744  12% + company-post-command
>         368,131   0% + redisplay_internal (C function)
>         135,480   0% + timer-event-handler
>           7,442   0% + eldoc-pre-command-refresh-echo-area
>           2,640   0% + highlight-parentheses--initiate-highlight
>           2,112   0% + jit-lock--antiblink-post-command
>           1,056   0% + company-pre-command
>               0   0%   ...
>
> HZ



-- 
Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province



reply via email to

[Prev in Thread] Current Thread [Next in Thread]