bug#74561: [PATCH] Allow limiting the size of *Completions*

[Dmitry Gutov]

On 29/11/2024 16:45, Spencer Baugh wrote:
> > Hmm... interesting.  I expected it would be the computation of faces
> > from things like `completion-pcm--hilit-commonality`.
> >
> > Do you happen to know which part of `display-completion-list` is the
> > most costly?  is it the actual insertion into the buffer?
> A simple way to profile this is:
> (progn
>    (require 'profiler)
>    (profiler-reset)
>    (profiler-cpu-start 10000)
>    (completing-read ":" (mapcar #'number-to-string (number-sequence 0 100000)))
>    (profiler-cpu-stop)
>    (setq profiler-cpu-log (profiler-cpu-log))
>    (profiler-report-cpu))
>
> The biggest individual contributors of runtime are
> set/add-text-properties and insert.

Buffer text properties are implemented in terms of plists, so it makes 
sense that they're consing and contribute to GC churn.

Actually limiting the completions buffer to N completions makes a lot of 
sense from my POV - not in the least because it corresponds to rendering 
a completion popup (which only shows N lines), with similar big-O 
complexity.

I suppose supporting full C-s searches is something of a complication, 
though. In Xref buffer, we do such adjustments in post-command-hook (for 
line truncation).