GNU bug report logs - #74561
[PATCH] Allow limiting the size of *Completions*

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 74561 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: bug#74561: [PATCH] Allow limiting the size of *Completions*
Date: Sat, 30 Nov 2024 19:17:14 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.