Observe Slowness In minibuffer-next-completion and friends

Observe Slowness In minibuffer-next-completion and friends

[T.V Raman]

This appears to be new as of this afternoon's update on Git:

Type:
C-h f next- <tab>
Then press down-arrow to move to next completion; the completion list
appears to be not active for about a second. I already tried setting
completion-highlight-face to nil, but the slowness remains; from
memory this feels new compared to yesterday


-- 

-- 

Re: Observe Slowness In minibuffer-next-completion and friends

[Eli Zaretskii]

> Date: Thu, 09 Nov 2023 20:08:10 -0800
> From: "T.V Raman" <raman@google.com>
> 
> This appears to be new as of this afternoon's update on Git:
> 
> Type:
> C-h f next- <tab>
> Then press down-arrow to move to next completion; the completion list
> appears to be not active for about a second. I already tried setting
> completion-highlight-face to nil, but the slowness remains; from
> memory this feels new compared to yesterday

Is this in "emacs -Q"?  If not, please tell which customizations are
necessary for reproducing this starting from "emacs -Q".  Because in
"emacs -Q" <DOWN> arrow is not supposed to move to the next completion
candidate.

Re: Observe Slowness In minibuffer-next-completion and friends

[T.V Raman]

Eli Zaretskii <eliz@gnu.org> writes:

It's emacs with all custom options as I have in my environment; reducing
 it to emacs -q then turning off the new minibuffer-completion nav will
 take some time.

For what it's worth, I turned on debug-on-quit and hit C-g during the
slowness but it appears that emacs in that state is not accepting any
input -- ie C-g quit and entered the debugger only after the hankiness
was done.>> Date: Thu, 09 Nov 2023 20:08:10 -0800
>> From: "T.V Raman" <raman@google.com>
>> 
>> This appears to be new as of this afternoon's update on Git:
>> 
>> Type:
>> C-h f next- <tab>
>> Then press down-arrow to move to next completion; the completion list
>> appears to be not active for about a second. I already tried setting
>> completion-highlight-face to nil, but the slowness remains; from
>> memory this feels new compared to yesterday
>
> Is this in "emacs -Q"?  If not, please tell which customizations are
> necessary for reproducing this starting from "emacs -Q".  Because in
> "emacs -Q" <DOWN> arrow is not supposed to move to the next completion
> candidate.

-- 

Re: Observe Slowness In minibuffer-next-completion and friends

[Juri Linkov]

> This appears to be new as of this afternoon's update on Git:
>
> Type:
> C-h f next- <tab>
> Then press down-arrow to move to next completion; the completion list
> appears to be not active for about a second. I already tried setting
> completion-highlight-face to nil, but the slowness remains; from
> memory this feels new compared to yesterday

The first time I tried it was very slow, it took about 3 seconds.
Then on next attempts it was instantaneous.  This means only one thing
that you have to wait a little until asynchronous native compilation
finishes its job.

That said, I think there are more opportunities for optimization.
What I don't like is that it checks the presence of the completions
window for the every key pressed.  A possible optimization would be
to set a minibuffer-local variable when the completions window
is displayed, and unset it when the window disappears.  However,
still can't handle the case when the user closes the completions
window manually with e.g. 'C-x 0'.

Re: Observe Slowness In minibuffer-next-completion and friends

[T.V Raman]

Juri Linkov <juri@linkov.net> writes:

I dont have native compilation enabled, so the async path likely plays
no role in this?
>> This appears to be new as of this afternoon's update on Git:
>>
>> Type:
>> C-h f next- <tab>
>> Then press down-arrow to move to next completion; the completion list
>> appears to be not active for about a second. I already tried setting
>> completion-highlight-face to nil, but the slowness remains; from
>> memory this feels new compared to yesterday
>
> The first time I tried it was very slow, it took about 3 seconds.
> Then on next attempts it was instantaneous.  This means only one thing
> that you have to wait a little until asynchronous native compilation
> finishes its job.
>
> That said, I think there are more opportunities for optimization.
> What I don't like is that it checks the presence of the completions
> window for the every key pressed.  A possible optimization would be
> to set a minibuffer-local variable when the completions window
> is displayed, and unset it when the window disappears.  However,
> still can't handle the case when the user closes the completions
> window manually with e.g. 'C-x 0'.

--