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==?= 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: References: <20190213212413.868.40960@vcs0.savannah.gnu.org> <20190213212415.148B9209D7@vcs0.savannah.gnu.org> <0ba3ca47-c7d6-a608-536e-94784ba3384b@yandex.ru> <4f4e9ccd-b152-2b37-cad2-6c96b0a64d84@yandex.ru> <646c8d35-89a7-b12f-8a78-b05e6d8f781c@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 , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 20 11:16:00 2019 Return-path: 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 ) 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 ) 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 ) 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 ) 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 ) 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 ; 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: (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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234398 Archived-At: Dmitry Gutov 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