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

["João Távora" <joaotavora@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> As I pointed out later in the email you're replying to, copying won't
> happen N times.

_Currently_, as in origin/master,  it happens N times.

In my patch, when a frontend adheres to the thing, it happens D times
where D is the amount of strings you need to display.  I guess if you do
the work to adapt a frontend to work with the new API proposed in
Daniel's patch it will be about the same (though likely in many more
lines of Elisp).

> First of all, note that scoring is only essential to the 'flex'
> style. Whereas the improvements we're discussing should benefit all,
> and can be more pronounced if the scoring don't need to be performed.

Yep, I agree.  But I don't see why the same principles I espouse --
which really amount to: let the style know it doesn't need to
face-propertize -- can't be applied to other styles that don't need
scoring.  Although those don't seem to suffer from any performance
problems, at least I haven't seens any complaints/reports/mesurements
like you did for bug#48841.

> But ok, let's talk about flex in particular.

Yes, I think that is important since it is the style known to be least
performant by its very lax nature.

> I'm guessing you just skip the C step in your benchmarks? Which is
> something that breaks our current contract.

Right.  Skipping the 'C = Copying step' is the whole point.  It breaks
our contract because the completion styles currently promise to
"face"-propertize the string.  So this is why I propose to let the
completion-style know that it doesn't need to.  When it is told of that,
it is relieved of the necessity of copying the string.  It is the
frontend that will do that copy just before face-propertizing and
displaying the string.  As you note, and reality shows, that's much
faster.  There is no disagreement here.

> Still, Daniel's patch should provide a comparable performance

Kinf of, from what I've read, it _should_ open the way for that to
happen.  From what I understand, you must then change the frontend (in a
big way?) to stop using completion-all-completions and start using the
new thing.  That work has not been done, as far as I know.  Whereas in
my proposal (which is now a patch posted to bug#48841) you change the
frontend in a very minor way, and that work _has_ been done.

Icomplete was very easy to adapt.  I can try adapting company soon.

In practice, we can't kill off completion-all-completions and start
everyone on completion-filter-completions (if that's what it's called).
So if the latter does turn out to be a step in the right direction (I'm
mostly waiting on Stefan to chime in), then I also don't see why we
couldn't have, as Eli suggested, both strategies for lazy highlighting
at some point in the future.

> improvement. If you're saying it doesn't give numbers as good, I'll
> have to give it a more thorough read and testing tomorrow to comment
> on that.

It's not me who is saying it, it's my Emacs :-) The real problem is that
with Daniel's patch, the frontends using the current API (as in
icomplete/fido) measurably become _slower_.  Though not by much (around
10%), it is still a shame.

Yes, do your testing and please, as always, try to report as
quantitatively as possible, so that we can really compare apples to
apples.

João