Too long completion delay time in LISP interaction mode.

Too long completion delay time in LISP interaction mode.

[Hongyi Zhao]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

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?

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

[-- Attachment #2: Selection_004.png --]
[-- Type: image/png, Size: 173009 bytes --]

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

[Emanuel Berg via Users list for the GNU Emacs text editor]

Hongyi Zhao wrote:

> On Ubuntu 20.04.3 LTS, I'm using the self compiled Emacs git
> master version [...]

You can use C-u M-x emacs-version RET

or (emacs-version t)
                    ^ eval me

GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
1.16.0) of 2021-10-04

-- 
underground experts united
https://dataswamp.org/~incal

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

[Hongyi Zhao]

On Wed, Oct 20, 2021 at 12:11 PM Emanuel Berg via Users list for the
GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> Hongyi Zhao wrote:
>
> > On Ubuntu 20.04.3 LTS, I'm using the self compiled Emacs git
> > master version [...]
>
> You can use C-u M-x emacs-version RET
>
> or (emacs-version t)
>                     ^ eval me

GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
cairo version 1.16.0)
of 2021-10-11

> GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
> 1.16.0) of 2021-10-04
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>


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

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

[Tassilo Horn]

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
`completion-category-overrides' if you have customized that).  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").

HTH,
Tassilo

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

[Hongyi Zhao]

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)


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

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

[Tassilo Horn]

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

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

> 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.  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).

Bye,
Tassilo

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

[Hongyi Zhao]

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

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

[Tassilo Horn]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

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

Well, again you didn't expand the lambda where most of the time is
spent...

>> 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':

I also use corfu but I think now I know what happens.  The thing is that
doing M-x profiler-report RET takes much longer (88% of the profiling
time) than computing the completion candidates.  That is done in the

    45   8% + ...

part which you should also expand.

When I do your recipe, the first 54% part is also the M-x
profiler-report RET part, and the

         327  45% - ...

is the actual completion part (using vertico).

--8<---------------cut here---------------start------------->8---
         391  54% - command-execute
         391  54%  - call-interactively
         390  53%   - byte-code
         390  53%    - read-extended-command
         390  53%     - completing-read
         390  53%      - completing-read-default
         390  53%       - apply
         390  53%        - vertico--advice
         390  53%         - apply
         390  53%          - #<compiled 0x8411fe8870440ec>
         375  51%           - read-from-minibuffer
         357  49%            + vertico--exhibit
           5   0%            + command-execute
           1   0%   + funcall-interactively
         327  45% - ...
         265  36%  - or
         265  36%   - if
         265  36%    - let*
         260  35%     - unwind-protect
         260  35%      - progn
         129  17%       + corfu--recompute-candidates
         121  16%       + let*
          10   1%       + if
           5   0%     + if
          62   8%    Automatic GC
           5   0% + timer-event-handler
--8<---------------cut here---------------end--------------->8---

HTH,
Tassilo

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

[Hongyi Zhao]

On Wed, Oct 20, 2021 at 2:25 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> 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)
>
> Well, again you didn't expand the lambda where most of the time is
> spent...

To be frank, I don't know how to expand it.

> >> 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':
>
> I also use corfu but I think now I know what happens.  The thing is that
> doing M-x profiler-report RET takes much longer (88% of the profiling
> time) than computing the completion candidates.  That is done in the
>
>     45   8% + ...
>
> part which you should also expand.

Again, I don't know how to expand it.

> When I do your recipe, the first 54% part is also the M-x
> profiler-report RET part, and the
>
>          327  45% - ...
>
> is the actual completion part (using vertico).

I don't use corfu [1] and vertico [2], but thank you for letting me
your configuration.

[1] https://github.com/minad/corfu
[2] https://github.com/minad/vertico


> --8<---------------cut here---------------start------------->8---
>          391  54% - command-execute
>          391  54%  - call-interactively
>          390  53%   - byte-code
>          390  53%    - read-extended-command
>          390  53%     - completing-read
>          390  53%      - completing-read-default
>          390  53%       - apply
>          390  53%        - vertico--advice
>          390  53%         - apply
>          390  53%          - #<compiled 0x8411fe8870440ec>
>          375  51%           - read-from-minibuffer
>          357  49%            + vertico--exhibit
>            5   0%            + command-execute
>            1   0%   + funcall-interactively
>          327  45% - ...
>          265  36%  - or
>          265  36%   - if
>          265  36%    - let*
>          260  35%     - unwind-protect
>          260  35%      - progn
>          129  17%       + corfu--recompute-candidates
>          121  16%       + let*
>           10   1%       + if
>            5   0%     + if
>           62   8%    Automatic GC
>            5   0% + timer-event-handler
> --8<---------------cut here---------------end--------------->8---

Anyway, after disabling the hotfuzz, the completion delay has been
reduced to an acceptable time.

[3] https://github.com/axelf4/hotfuzz

HZ

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

[Tassilo Horn]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

>> I also use corfu but I think now I know what happens.  The thing is
>> that doing M-x profiler-report RET takes much longer (88% of the
>> profiling time) than computing the completion candidates.  That is
>> done in the
>>
>>     45   8% + ...
>>
>> part which you should also expand.
>
> Again, I don't know how to expand it.

You hit RET on the line.

> Anyway, after disabling the hotfuzz, the completion delay has been
> reduced to an acceptable time.

That's what I guessed.  It might make sense to have some fuzzy style
(like hotfuzz or the built-in flex) as last entry in
`completion-styles', though.  FWIW, I use

  (setq completion-styles '(partial-completion substring flex))

and

  (setq completion-category-overrides
        '((project-file
           (styles partial-completion substring initials))
          (file
           (styles partial-completion substring initials))
          (eglot
           (styles partial-completion substring))))

Bye,
Tassilo

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

[Hongyi Zhao]

On Wed, Oct 20, 2021 at 3:24 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> I also use corfu but I think now I know what happens.  The thing is
> >> that doing M-x profiler-report RET takes much longer (88% of the
> >> profiling time) than computing the completion candidates.  That is
> >> done in the
> >>
> >>     45   8% + ...
> >>
> >> part which you should also expand.
> >
> > Again, I don't know how to expand it.
>
> You hit RET on the line.
>
> > Anyway, after disabling the hotfuzz, the completion delay has been
> > reduced to an acceptable time.
>
> That's what I guessed.  It might make sense to have some fuzzy style
> (like hotfuzz or the built-in flex) as last entry in
> `completion-styles', though.  FWIW, I use
>
>   (setq completion-styles '(partial-completion substring flex))
>
> and
>
>   (setq completion-category-overrides
>         '((project-file
>            (styles partial-completion substring initials))
>           (file
>            (styles partial-completion substring initials))
>           (eglot
>            (styles partial-completion substring))))

Thank you for sharing your experience.

HZ

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

[Hongyi Zhao]

On Wed, Oct 20, 2021 at 3:24 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> I also use corfu but I think now I know what happens.  The thing is
> >> that doing M-x profiler-report RET takes much longer (88% of the
> >> profiling time) than computing the completion candidates.  That is
> >> done in the
> >>
> >>     45   8% + ...
> >>
> >> part which you should also expand.
> >
> > Again, I don't know how to expand it.
>
> You hit RET on the line.
>
> > Anyway, after disabling the hotfuzz, the completion delay has been
> > reduced to an acceptable time.
>
> That's what I guessed.  It might make sense to have some fuzzy style
> (like hotfuzz or the built-in flex) as last entry in
> `completion-styles', though.  FWIW, I use
>
>   (setq completion-styles '(partial-completion substring flex))
>
> and
>
>   (setq completion-category-overrides
>         '((project-file
>            (styles partial-completion substring initials))
>           (file
>            (styles partial-completion substring initials))
>           (eglot

Can the above line be changed into the following?

             ((eglot lsp)


>            (styles partial-completion substring))))
>
> Bye,
> Tassilo



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

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

[Tassilo Horn]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

>>   (setq completion-category-overrides
>>         '((project-file
>>            (styles partial-completion substring initials))
>>           (file
>>            (styles partial-completion substring initials))
>>           (eglot
>
> Can the above line be changed into the following?
>
>              ((eglot lsp)

The docs suggest that the keys are one CATEGORY, not a list of
categories.  But you can duplicate the eglot entry for lsp, assuming
that lsp-mode defines its own completion category which I don't know
(since I use eglot for my LSP interaction).

Bye,
Tassilo

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

[Hongyi Zhao]

On Thu, Oct 21, 2021 at 1:47 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >>   (setq completion-category-overrides
> >>         '((project-file
> >>            (styles partial-completion substring initials))
> >>           (file
> >>            (styles partial-completion substring initials))
> >>           (eglot
> >
> > Can the above line be changed into the following?
> >
> >              ((eglot lsp)
>
> The docs suggest that the keys are one CATEGORY, not a list of
> categories.  But you can duplicate the eglot entry for lsp,

Thank you for pointing this out.

> assuming that lsp-mode defines its own completion category which I don't know
> (since I use eglot for my LSP interaction).

They are defined as follows:

https://github.com/emacs-lsp/lsp-mode/blob/1ece3b81ad10d1b10a2c73c6617b4426e673cbc7/lsp-completion.el#L745

(make-local-variable 'completion-category-defaults)
(setf (alist-get 'lsp-capf completion-category-defaults) '((styles .
(lsp-passthrough))))


https://github.com/emacs-lsp/lsp-mode/blob/1ece3b81ad10d1b10a2c73c6617b4426e673cbc7/lsp-completion.el#L775

(setq-local completion-category-defaults
(cl-remove 'lsp-capf completion-category-defaults :key #'cl-first))


So, I adjusted to the following configuration based on orderless package:

(use-package orderless
  :config
  ;; https://github.com/oantolin/orderless#ivy
  (setq ivy-re-builders-alist '((t . orderless-ivy-re-builder))
    completion-styles '(partial-completion substring flex orderless)
    completion-category-overrides
    '((project-file
       (styles partial-completion substring initials))
      (file
       (styles partial-completion substring initials))
      (eglot
       (styles partial-completion substring))
      (lsp
       (styles partial-completion substring))
      )))

HZ

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

[Tassilo Horn]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

>> assuming that lsp-mode defines its own completion category which I don't know
>> (since I use eglot for my LSP interaction).
>
> They are defined as follows:
>
> https://github.com/emacs-lsp/lsp-mode/blob/1ece3b81ad10d1b10a2c73c6617b4426e673cbc7/lsp-completion.el#L745
>
> (make-local-variable 'completion-category-defaults)
> (setf (alist-get 'lsp-capf completion-category-defaults) '((styles .
> (lsp-passthrough))))

That might suggest that lsp-mode wants its own `lsp-passthrough' style
and nothing else, not sure.

> So, I adjusted to the following configuration based on orderless package:
>
> (use-package orderless
>   :config
>   ;; https://github.com/oantolin/orderless#ivy
>   (setq ivy-re-builders-alist '((t . orderless-ivy-re-builder))
>     completion-styles '(partial-completion substring flex orderless)
>     completion-category-overrides
>     '((project-file
>        (styles partial-completion substring initials))
>       (file
>        (styles partial-completion substring initials))
>       (eglot
>        (styles partial-completion substring))
>       (lsp
>        (styles partial-completion substring))

The definition you've cited says `lsp-capf', not just `lsp'.

Bye,
Tassilo

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

[Hongyi Zhao]

On Thu, Oct 21, 2021 at 4:53 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> assuming that lsp-mode defines its own completion category which I don't know
> >> (since I use eglot for my LSP interaction).
> >
> > They are defined as follows:
> >
> > https://github.com/emacs-lsp/lsp-mode/blob/1ece3b81ad10d1b10a2c73c6617b4426e673cbc7/lsp-completion.el#L745
> >
> > (make-local-variable 'completion-category-defaults)
> > (setf (alist-get 'lsp-capf completion-category-defaults) '((styles .
> > (lsp-passthrough))))
>
> That might suggest that lsp-mode wants its own `lsp-passthrough' style
> and nothing else, not sure.
>
> > So, I adjusted to the following configuration based on orderless package:
> >
> > (use-package orderless
> >   :config
> >   ;; https://github.com/oantolin/orderless#ivy
> >   (setq ivy-re-builders-alist '((t . orderless-ivy-re-builder))
> >     completion-styles '(partial-completion substring flex orderless)
> >     completion-category-overrides
> >     '((project-file
> >        (styles partial-completion substring initials))
> >       (file
> >        (styles partial-completion substring initials))
> >       (eglot
> >        (styles partial-completion substring))
> >       (lsp
> >        (styles partial-completion substring))
>
> The definition you've cited says `lsp-capf', not just `lsp'.

Thank you for pointing this out.

HZ

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

[Hongyi Zhao]

On Wed, Oct 20, 2021 at 2:42 PM Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> On Wed, Oct 20, 2021 at 2:25 PM Tassilo Horn <tsdh@gnu.org> wrote:
> >
> > Hongyi Zhao <hongyi.zhao@gmail.com> writes:
> >
> > >> 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)
> >
> > Well, again you didn't expand the lambda where most of the time is
> > spent...
>
> To be frank, I don't know how to expand it.

Shame on me. It can be expanded by clicking the + sign again and
again. See the following:

         495  86% - command-execute
         495  86%  - funcall-interactively
         487  85%   - counsel-M-x
         487  85%    - let
         458  80%     - ivy-read
         458  80%      - apply
         454  79%       - #<lambda 0x1de0670da47deef2>
         454  79%        - let*
         454  79%         - progn
         454  79%          - progn
         454  79%           - let*
         404  70%            - ivy--reset-state
         404  70%             - let*
         404  70%              - let
         344  60%               - if
         340  59%                - progn
         340  59%                 - setq
         336  58%                  - sort
         308  54%                   - ivy-prescient-sort-function
         264  46%                    - prescient-sort-compare
         180  31%                     - let
         172  30%                      - progn
         160  28%                       - let*
         124  21%                        - or
         116  20%                         - and
          64  11%                          - let*
          36   6%                           - or
          32   5%                            - and
          20   3%                               <
           4   0%                     - if
           4   0%                        and
           4   0%                - and
           4   0%                   null
          60  10%               - cond
          60  10%                - let
          60  10%                 - setq
          44   7%                  - all-completions
          36   6%                   - #<lambda 0x543b56196f44733>
          36   6%                    - and
           4   0%                     - not
           4   0%                        get
          39   6%            - unwind-protect
          39   6%             - let
          39   6%              - unwind-protect
          39   6%               - progn
          39   6%                - let*
          39   6%                 - if
          39   6%                  - condition-case
          35   6%                   - read-from-minibuffer
          21   3%                    - ivy--queue-exhibit
          21   3%                     - if
          21   3%                      - ivy--exhibit
          21   3%                       - if
          21   3%                        - progn
          21   3%                         - let
          21   3%                          - ivy--update-minibuffer
          21   3%                           - prog1
          21   3%                            - if
          11   1%                             - save-current-buffer
          11   1%                              + ivy--format
          10   1%                             + progn
           3   0%                    + redisplay_internal (C function)
          11   1%            + ivy-call
           4   0%       + posframe-show
          29   5%     - counsel--M-x-externs
          29   5%        cond
           8   1%   - self-insert-command
           8   1%    - hideshowvis-highlight-hs-regions-in-fringe
           8   1%     - if
           8   1%      - progn
           8   1%       - save-excursion
           8   1%        - save-restriction
           8   1%           while
          65  11% - ...
          44   7%  - completion-all-completions
          44   7%   - completion--nth-completion
          44   7%    - completion--some
          44   7%     - #<compiled 0x194abcb52c81cd5e>
          44   7%      - orderless-all-completions
          44   7%       - let
          44   7%        - orderless-filter
          44   7%         - let
          44   7%          - unwind-protect
          44   7%           - progn
          44   7%            - let*
          44   7%             - progn
          44   7%              - let*
          44   7%               - let
          44   7%                - let*
          44   7%                   progn
          13   2%  - window-text-pixel-size
          13   2%   - jit-lock-function
          13   2%    - jit-lock-fontify-now
          13   2%     - jit-lock--run-functions
          13   2%      - run-hook-wrapped
          13   2%       - #<compiled 0x19ba2d83e5235cbd>
          13   2%        - adaptive-wrap-prefix-function
          13   2%         - while
          13   2%          - let
           5   0%           - company-call-backend
           5   0%            - company--force-sync
           5   0%             - let
           5   0%              - apply
           5   0%               - company-call-backend-raw
           5   0%                - condition-case
           5   0%                 - if
           5   0%                  - apply
           5   0%                   - company-capf
           5   0%                    - apply
           5   0%                     - company-anywhere-capf
           5   0%                      - if
           5   0%                       - apply
           5   0%                        - #<lambda -0x10ca152207b458d5>
           5   0%                           cond
           4   0%           - nconc
           4   0%            - if
           4   0%             - orderless-highlight-matches
           4   0%              - let*
           4   0%               - while
           4   0%                - setq
           4   0%                 - cons
           4   0%                  - orderless--highlight
           4   0%                   - let*
           4   0%                    - let
           4   0%                     - while
           4   0%                      - if
           4   0%                       - progn
           4   0%                        - let*
           4   0%                           let
           4   0%           - put-text-property
           4   0%            - let
           4   0%             - adaptive-wrap-fill-context-prefix
           4   0%              - let*
           4   0%               - or
           4   0%                - let
           4   0%                   fill-context-prefix
           8   1%  - ivy--filter
           8   1%   - let
           8   1%    - if
           8   1%     - let*
           8   1%      - cond
           8   1%       - ivy--re-filter
           8   1%        - if
           8   1%         - condition-case
           8   1%          - progn
           8   1%           - let
           8   1%            - while
           8   1%             - let
           8   1%              - let*
           8   1%               - setq
           4   0%                + company-calculate-candidates
           4   0%                + cl-remove
           0   0%    Automatic GC
          10   1% + 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':
> >
> > I also use corfu but I think now I know what happens.  The thing is that
> > doing M-x profiler-report RET takes much longer (88% of the profiling
> > time) than computing the completion candidates.  That is done in the
> >
> >     45   8% + ...
> >
> > part which you should also expand.
>
> Again, I don't know how to expand it.
>
> > When I do your recipe, the first 54% part is also the M-x
> > profiler-report RET part, and the
> >
> >          327  45% - ...
> >
> > is the actual completion part (using vertico).
>
> I don't use corfu [1] and vertico [2], but thank you for letting me
> your configuration.
>
> [1] https://github.com/minad/corfu
> [2] https://github.com/minad/vertico
>
>
> > --8<---------------cut here---------------start------------->8---
> >          391  54% - command-execute
> >          391  54%  - call-interactively
> >          390  53%   - byte-code
> >          390  53%    - read-extended-command
> >          390  53%     - completing-read
> >          390  53%      - completing-read-default
> >          390  53%       - apply
> >          390  53%        - vertico--advice
> >          390  53%         - apply
> >          390  53%          - #<compiled 0x8411fe8870440ec>
> >          375  51%           - read-from-minibuffer
> >          357  49%            + vertico--exhibit
> >            5   0%            + command-execute
> >            1   0%   + funcall-interactively
> >          327  45% - ...
> >          265  36%  - or
> >          265  36%   - if
> >          265  36%    - let*
> >          260  35%     - unwind-protect
> >          260  35%      - progn
> >          129  17%       + corfu--recompute-candidates
> >          121  16%       + let*
> >           10   1%       + if
> >            5   0%     + if
> >           62   8%    Automatic GC
> >            5   0% + timer-event-handler
> > --8<---------------cut here---------------end--------------->8---
>
> Anyway, after disabling the hotfuzz, the completion delay has been
> reduced to an acceptable time.
>
> [3] https://github.com/axelf4/hotfuzz
>
> HZ

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

[Tassilo Horn]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

>> To be frank, I don't know how to expand it.
>
> Shame on me. It can be expanded by clicking the + sign again and
> again.

Hehe. :-)

> See the following:
>
>          495  86% - command-execute
>          495  86%  - funcall-interactively
>          487  85%   - counsel-M-x
>          487  85%    - let
>          458  80%     - ivy-read
>          458  80%      - apply
>          454  79%       - #<lambda 0x1de0670da47deef2>
>          454  79%        - let*
>          454  79%         - progn
>          454  79%          - progn
>          454  79%           - let*
>          404  70%            - ivy--reset-state
>          404  70%             - let*
>          404  70%              - let
>          344  60%               - if
>          340  59%                - progn
>          340  59%                 - setq
>          336  58%                  - sort
>          308  54%                   - ivy-prescient-sort-function
>          264  46%                    - prescient-sort-compare

So here you can see that prescient seems to have quite some impact on
sorting the candidates for M-x.

>           65  11% - ...
>           44   7%  - completion-all-completions
>           44   7%   - completion--nth-completion
>           44   7%    - completion--some
>           44   7%     - #<compiled 0x194abcb52c81cd5e>
>           44   7%      - orderless-all-completions
>           44   7%       - let
>           44   7%        - orderless-filter
>           44   7%         - let
>           44   7%          - unwind-protect
>           44   7%           - progn
>           44   7%            - let*
>           44   7%             - progn
>           44   7%              - let*
>           44   7%               - let
>           44   7%                - let*
>           44   7%                   progn

And the above is the actual "(map" completion part which seems to be
dominated by the orderless style.  So I guess you've now replaced
hotfuzz with orderless, right?

Bye,
Tassilo

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

[Hongyi Zhao]

On Wed, Oct 20, 2021 at 3:42 PM Tassilo Horn <tsdh@gnu.org> wrote:
>
> Hongyi Zhao <hongyi.zhao@gmail.com> writes:
>
> >> To be frank, I don't know how to expand it.
> >
> > Shame on me. It can be expanded by clicking the + sign again and
> > again.
>
> Hehe. :-)
>
> > See the following:
> >
> >          495  86% - command-execute
> >          495  86%  - funcall-interactively
> >          487  85%   - counsel-M-x
> >          487  85%    - let
> >          458  80%     - ivy-read
> >          458  80%      - apply
> >          454  79%       - #<lambda 0x1de0670da47deef2>
> >          454  79%        - let*
> >          454  79%         - progn
> >          454  79%          - progn
> >          454  79%           - let*
> >          404  70%            - ivy--reset-state
> >          404  70%             - let*
> >          404  70%              - let
> >          344  60%               - if
> >          340  59%                - progn
> >          340  59%                 - setq
> >          336  58%                  - sort
> >          308  54%                   - ivy-prescient-sort-function
> >          264  46%                    - prescient-sort-compare
>
> So here you can see that prescient seems to have quite some impact on
> sorting the candidates for M-x.

I use the following prescient relevant configuration:

--8<---------------cut here---------------start------------->8---
;;https://github.com/daviwil/emacs-from-scratch/wiki/LSP-Python-(pyright)-config-in-emacs-from-scratch#prescient
(use-package prescient
  :diminish
  :config
  (prescient-persist-mode)
  )


;;https://github.com/daviwil/emacs-from-scratch/wiki/LSP-Python-(pyright)-config-in-emacs-from-scratch#prescient-1
(use-package company-prescient
  :init (setq ;;https://github.com/company-mode/company-mode/issues/1141#issuecomment-884570548
         company-prescient-sort-length-enable nil)
  :config
  (company-prescient-mode 1)
  )

;;https://github.com/abo-abo/swiper/issues/2899#issuecomment-890300284
(use-package ivy-prescient
  :init
  (setq prescient-filter-method '(literal fuzzy regexp initialism)
    ;;https://github.com/raxod502/prescient.el#ivy-specific
        ivy-prescient-enable-filtering nil)
  :config
  ;;https://github.com/daviwil/emacs-from-scratch/wiki/LSP-Python-(pyright)-config-in-emacs-from-scratch#prescient
  (ivy-prescient-mode 1) ; According to my attempt, use this
configuration in :init will defeat swiper
  )
--8<---------------cut here---------------end------------->8---


> >           65  11% - ...
> >           44   7%  - completion-all-completions
> >           44   7%   - completion--nth-completion
> >           44   7%    - completion--some
> >           44   7%     - #<compiled 0x194abcb52c81cd5e>
> >           44   7%      - orderless-all-completions
> >           44   7%       - let
> >           44   7%        - orderless-filter
> >           44   7%         - let
> >           44   7%          - unwind-protect
> >           44   7%           - progn
> >           44   7%            - let*
> >           44   7%             - progn
> >           44   7%              - let*
> >           44   7%               - let
> >           44   7%                - let*
> >           44   7%                   progn
>
> And the above is the actual "(map" completion part which seems to be
> dominated by the orderless style.  So I guess you've now replaced
> hotfuzz with orderless, right?

To be frank, due to my negligence, I've set orderless first and then
hotfuzz in the init.el file at the same time. The following is the
configuration of orderless:

(use-package orderless
  :init (icomplete-mode)
  :custom (completion-styles '(orderless)))


After I disabled the hotfuzz, the orderless comes into play. But
fortunately, it seems that orderless doesn't have so much penalty on
performance. For convenience's sake, I decided to stick with it.

HZ

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

[Hongyi Zhao]

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

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

[Hongyi Zhao]

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

RE: [External] : Re: Too long completion delay time in LISP interaction mode.

[Drew Adams]

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

That's often the first thing to try, when
fumbling in the dark.  Just bisect your
init file till you find the culprit.

That's quick to do (though at first it
seems not to be quick).  You can use
`comment-region' to comment out a block
of code (a prefix arg uncomments).  Do
that to 1/2, then 1/4, 1/8, 1/16,... of
your init file.