From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@gmail.com>
Newsgroups: gmane.emacs.devel
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
Message-ID: <m1lg1950k1.fsf@gmail.com>
References: <20190213212413.868.40960@vcs0.savannah.gnu.org>
	<20190213212415.148B9209D7@vcs0.savannah.gnu.org>
	<0ba3ca47-c7d6-a608-536e-94784ba3384b@yandex.ru>
	<CALDnm53-7bkf0+c_pf1JNzkiRpfyuowONXXChTEfuzW_Ln7aXA@mail.gmail.com>
	<jwvva0j6jsb.fsf-monnier+emacs@gnu.org>
	<aeafbcc5-0466-af36-e646-22aa0ef1544c@yandex.ru>
	<CALDnm52k-NMs8jfUHj2UoT=AFj3byQZZ8HU-axOqz0n0bRf1Gw@mail.gmail.com>
	<4f4e9ccd-b152-2b37-cad2-6c96b0a64d84@yandex.ru>
	<CALDnm53WS=T4A1x-sMAwiEf3xYwza1v79YQ=nvp17o9c=VvpAw@mail.gmail.com>
	<646c8d35-89a7-b12f-8a78-b05e6d8f781c@yandex.ru>
	<CALDnm53_N8_A0Fz7Ck4AjTZQmYxAaLRtuec8+DhweYR5DNmx5g@mail.gmail.com>
	<ba298a2e-3ced-8cf8-8552-1a0ddbee4885@yandex.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
	logging-data="27903"; mail-complaints-to="usenet@blaine.gmane.org"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (darwin)
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
	emacs-devel <emacs-devel@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 20 11:16:00 2019
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Envelope-to: ged-emacs-devel@m.gmane.org
Original-Received: from lists.gnu.org ([209.51.188.17])
	by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1h6YGN-000775-27
	for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2019 11:15:59 +0100
Original-Received: from localhost ([127.0.0.1]:45529 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1h6YGL-0006m6-RS
	for ged-emacs-devel@m.gmane.org; Wed, 20 Mar 2019 06:15:57 -0400
Original-Received: from eggs.gnu.org ([209.51.188.92]:33283)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <joaotavora@gmail.com>) id 1h6YBy-0003Bt-Gi
	for emacs-devel@gnu.org; Wed, 20 Mar 2019 06:11:27 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <joaotavora@gmail.com>) id 1h6Y0B-0004eD-Vd
	for emacs-devel@gnu.org; Wed, 20 Mar 2019 05:59:16 -0400
Original-Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:46307)
	by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
	(Exim 4.71) (envelope-from <joaotavora@gmail.com>)
	id 1h6Y0B-0004cK-Gw
	for emacs-devel@gnu.org; Wed, 20 Mar 2019 05:59:15 -0400
Original-Received: by mail-wr1-x431.google.com with SMTP id o1so1966713wrs.13
	for <emacs-devel@gnu.org>; Wed, 20 Mar 2019 02:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:to:cc:subject:references:date:in-reply-to:message-id
	:user-agent:mime-version:content-transfer-encoding;
	bh=TQpR9JcK+Gw0ZoLfz+rUz5QJc+wwFGybG7y9ZnUI3+4=;
	b=OpJGM9FzXGlFwe7jOOekQMtI2B5uBVp8R9BCvYIe3ZcNCorPimq++dgWzloPVMmkfg
	3qK4x2hxAowm74yi8dDBTwF4bBHJA6+Xzo7aL7EZBmi5Yb44GA3l/bd3SrpAwuONkQn+
	YmzNQDA3YQmihOF0UGgytsTitHx6Ycj5kdJAPI0+6kDgqWQCA0RK7sYR3TH2Sj06Shkt
	FQeVrhKDbx6jz8kbD3GTH87T0mGePAshy1+W54Mr2NAqxYFojll8wo5TmtP2GN5Mqsc0
	nTlrXXl1RqtxFZbRYszDoWC3HXd/61xRw8oV6xlB2WkDZmBi8CrA/L+9wMF8juVc0L7I
	qq3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
	:message-id:user-agent:mime-version:content-transfer-encoding;
	bh=TQpR9JcK+Gw0ZoLfz+rUz5QJc+wwFGybG7y9ZnUI3+4=;
	b=r3S16ipUcne2ZBB1o6Hv4g8qpYMfTo/JmsPpmPRg6B8nDVnn2WJMdwHLR8uIAadvIS
	/qsXcNPgrYzV++pihWmGBmwhkAoJpADyFE5YxgCIVc6HFuqZHC3Ms5al9aBPgDoa290F
	dJgr/2tXcoY+OaARbxU6ibs/0FFoepTMYBWmP9O56UHv6WG7iO7brP2Di6P1cSi1dHI6
	4ZvJm4krN0eG6waMDqQqIVq6YQZlqbdzsE8xDposv7WvIgetG6qrdgMLNiVwKwHh4+Qt
	Ygyt8rKw8hIGQ1tmm3C96xmj0fRNEvAKlEbtvZP0fWEJrJoW5I/N7yStj/kCcGqrtFee
	bxaQ==
X-Gm-Message-State: APjAAAUJwUUxi+icavO1zMVC54dup0832dBgYUQhgeDdodXv5zWSEgMt
	Owqrqxe2JVxidfdY1+CT/VfifzZU
X-Google-Smtp-Source: APXvYqzMILfqtLnS2FlNRNSGdbLm36zbOunSNct3A/o8IUMP8n5VxgXs9s4RbXR4t795tuSy03Al1w==
X-Received: by 2002:adf:df92:: with SMTP id z18mr13052624wrl.239.1553075953502;
	Wed, 20 Mar 2019 02:59:13 -0700 (PDT)
Original-Received: from kitaj.local.yourcompany.com (188.139.62.94.rev.vodafone.pt.
	[94.62.139.188]) by smtp.gmail.com with ESMTPSA id
	e12sm1814544wrt.94.2019.03.20.02.59.12
	(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
	Wed, 20 Mar 2019 02:59:12 -0700 (PDT)
In-Reply-To: <ba298a2e-3ced-8cf8-8552-1a0ddbee4885@yandex.ru> (Dmitry Gutov's
	message of "Mon, 18 Mar 2019 19:18:57 +0200")
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
	recognized.
X-Received-From: 2a00:1450:4864:20::431
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel/>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.devel:234398
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/234398>

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 18.03.2019 16:51, Jo=C3=A3o T=C3=A1vora 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.

Jo=C3=A3o