Re: [Emacs-diffs] master b0e318d 2/2: Score flex-style completions according to match tightness

[Dmitry Gutov <dgutov@yandex.ru>]

On 18.03.2019 16:51, João Távora wrote:

>> Try a smaller input, like just 'k'. The difference is more stark in that
>> case, and the lists of completions are longer.
>>
>> For the same reason (lots of matches), I'm afraid simply moving matching
>> to C won't bring a noticeable improvement.
> 
> You're partly right. With shorter input, the burden shifts considerably
> from completion-pcm--all-completions (the matching) to
> completion-pcm--hilit-commonality (the hilighting and scoring), but
> according to the CPU profiler, the former is still dominant, so even a
> modest improvement there could still have a large impact.

I was actually comparing flex vs basic in this scenario, and the former 
was 2x slower. Which is, IDK, could be noticeable.

> Capping max matches (after sorting) might bring more improvements
> to parts of the code that I'm not profiling (like stuff that iterates all
> matches, though I'm not sure what), or by releasing large parts of the
> list early for the GC to reap.

Capping max matches is what all completion systems do in other editors, 
AFAIK. That feels kind of dirty, but could bring the most bang for the 
effort expended.

As long as we don't confuse any caches by doing this.

Also, the limit has to come *after* scoring and sorting, so for the 
performance improvement to arrive, it seems a lot of things would need 
to migrate to C.

> As can other techniques like deferring the completion with an idle
> timer which is reset on every keystroke.  I'm reasonably confortable
> with this last technique and it is usually desirable regardless of other
> speed improvements, so I might have a look at that first.

It's worth a try. But if filtering will happen right away after the user 
has stopped typing, that might mean higher CPU usage and lower battery 
life on a laptop. Just something to be on a lookout for.