GNU bug report logs -
#47711
27.1; Deferred highlighting support in `completion-all-completions', `vertico--all-completions`
Previous Next
Reported by: Daniel Mendler <mail <at> daniel-mendler.de>
Date: Sun, 11 Apr 2021 20:52:01 UTC
Severity: normal
Found in version 27.1
Done: Daniel Mendler <mail <at> daniel-mendler.de>
Bug is archived. No further changes may be made.
Full log
Message #332 received at 47711 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dmitry <at> 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
This bug report was last modified 172 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.