[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master b0e318d 2/2: Score flex-style completions accor

From: Dmitry Gutov
Subject: Re: [Emacs-diffs] master b0e318d 2/2: Score flex-style completions according to match tightness
Date: Mon, 18 Mar 2019 19:18:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]