[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: João Távora
Subject: Re: [Emacs-diffs] master b0e318d 2/2: Score flex-style completions according to match tightness
Date: Wed, 20 Mar 2019 09:59:10 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (darwin)

Dmitry Gutov <address@hidden> writes:

> On 18.03.2019 16:51, João Távora wrote:
>> 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.

I understood that.  I was just saying that in the "2x slower" case, well
more than half of the time is still spent in
completion-pcm--all-completions.  This time is potentially spent
matching regexps (but maybe not, I haven't dug down from there).  But if
it is, it could be optimizable by hand-coding the matching code in C, so
there still seems to be an opportunity for considerably reducing that 2x
slowdown when comparing to basic.

> 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.

I don't think that's practical.  As I said, if capping max matches is to
have any effects, it will be in parts of code that I haven't profiled,
i.e. parts that aren't as simple to profile as calling
completion-all-completion.  Those would presumably be in the UI's
(icomplete, company) and would somehow iterate all the list. But perhaps
there aren't that many parts.

>> 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.

You're absolutely right.  And anyway I noticed icomplete _already_ has a
while-no-input there, so that technique has already been tried.  I guess
the most annoying thing here in terms of user experience is a variation
on this: C-h f RET typed in quick succession on an elisp functino will
see a considerable delay after typing the 'f' that really shouldn't be
there.  In other words, typing this very fast just means I know in
advance what the default will be and am OK with it, so I expect no
completions-related delay.  Bomehow even with the while-no-input and
with icomplete-compute-delay to 0 this still happens, so this is where
I'm going to investigate.


reply via email to

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