bug#47711: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting

[João Távora]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 27/10/2023 20:16, João Távora wrote:

> Thanks. My measurements are similar, except the difference switch the
> other way a little bit. It might depend on the particulars of the
> individual machine anyway.

Yes, it could, but I've reproduced this in different hardware.

Check that you're taking enough samples, I take about 15-20 samples.
Maybe the lazy-hilit patch pays a an extra cost upfront for the very
first C-h v or completing-read, to create the properties keys on the
strings, which are then reused.  This cost is ammortized very quickly,
of course, but if you're taking the measurement immediately after Emacs
-Q and with few samples, it skews the numbers.

> All averages made using 'M-x calc-grab-region' followed by 'u M'.

Wow, thanks for this tip.  I wondered if there was an easier way than
M-x cua-rectangle-mark-mode + hand rolled avg function.

> I just meant that your version will be easier to use in
> company--match-from-capf-face (because it works on individual
> completions).

Ah, that was my intution too.  I misunderstood you then, I thought you
meant the list version would be easier and I found that odd.

>>> Third, it made a principled stance to avoid altering the original
>>> strings, even the non-visual text properties. This approach could be
>>> adopted piecewise from Daniel's patch, especially if the performance
>>> ends up the same or insignificantly different in practical usage.
>> If we really wanted to, we could also adopt the non-propertizing
>> approach in my lazy-hilit patch, by calculating the score "just in
>> time", much like Daniel's patch does it.  But it should be clear that
>> what we save in allocation in completion-pcm--hilit-commonality, we'll
>> pay for in the same amount in consing later.  So no performance benefit.
>
> Not for performance, no. Although the way it separates the sorting
> into its own phase makes it easier to reason about that particular
> cost. And for 300000 symbols, scoring and sorting really take the most
> time, e.g. about 2/3rds. Which might help with optimizing it further
> down in the future, somehow,

I think further optimization would be localized to the scoring function
itself, not to the place where it is performed.

> But if course it would be nice to avoid the wart, so if you have any
> better ideas, they are welcome.

I'm not saying it would necessarily spread even further, but if you want
to do scoring "just in time" like I suggested -- presumably to
completely avoid propertizing strings -- that particular wart spreads a
little more and thus becomes something that is slightly harder to remove
later on.

> So far you advocated toward avoiding breaking changes while
> implementing the present performance improvement.

Both patches do that, so what I've been arguing for is simplicity and
coherence.  I don't think completion-sorted-completions and the
complexity it brings to minibuffer.el is a step in the rigth direction,
and the performance benefits it does undeniably bring can be achieved
with less drastic means.

João