From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Sat, 14 Aug 2021 10:48:28 +0100 Message-ID: <877dgo8ihf.fsf@gmail.com> References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <83im08bjc3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14842"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Daniel Mendler , 47711@debbugs.gnu.org, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 14 11:49:16 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mEqHz-0003ba-JT for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 11:49:15 +0200 Original-Received: from localhost ([::1]:35978 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEqHx-00081W-Oh for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 14 Aug 2021 05:49:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36982) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEqHn-00081F-01 for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 05:49:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60263) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mEqHm-0002zT-PJ for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 05:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mEqHm-0007cB-Nw for bug-gnu-emacs@gnu.org; Sat, 14 Aug 2021 05:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 09:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs Original-Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162893452729234 (code B ref 48841); Sat, 14 Aug 2021 09:49:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 09:48:47 +0000 Original-Received: from localhost ([127.0.0.1]:43573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEqHT-0007bL-MA for submit@debbugs.gnu.org; Sat, 14 Aug 2021 05:48:47 -0400 Original-Received: from mail-wm1-f49.google.com ([209.85.128.49]:53088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEqHO-0007at-6L; Sat, 14 Aug 2021 05:48:42 -0400 Original-Received: by mail-wm1-f49.google.com with SMTP id f10so5259283wml.2; Sat, 14 Aug 2021 02:48:38 -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; bh=IS4QwsDKH6F4eWyXx6K0rL7ucoThMsH5rpcQmB+fRc8=; b=OJdEtXu9nvilRpB8PfhTS6L2QOIUYP043g1Fv82poBBkAx3FMobRNV1sXK/U6hBEuz CKZNa6is7lzW4Tc8z0noc1ahwfzUYbJu8Qo2MiDd5klm3iID/SnCbJ+BYOgX3ZYUPBGK TnJrQV1xxyrmdgekIX5EmLf2LoCJHWkWIOPldExlzNAGIpGurhdpVN4wZtU2/Ik4QaiC 6vdRwmIGFh6WJWO7XhZjO9M+2FLA/OuyI8Mf3VozvOW1idEThkzIyRiJNb7OpeTdFWAk 8jN8fsvCY/l8DMmY2i50pWkJ9BU5cV726+1CZ4YyRYHAkPTFvOU16GIxTUWcuKgqnQJN WF/g== 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; bh=IS4QwsDKH6F4eWyXx6K0rL7ucoThMsH5rpcQmB+fRc8=; b=DK8hkUSafjUj7HKuFo4qv4tNEUmLFRwhLN3rddJVozkV8G/tJ8S5f8AHWKyR7agxEu A4hCPcrjHp9iexu1GSoqWHGZpFqLzav63fEkQTwLIaoNk/qGHP1xW+MQh4GzG9fvBrMh DrHGm/ZG4CQwdmbb5iff6n2UlKGZZTt/L3KAx/QWb2RRrRSquqS6sZmkRaA4Ht8/Jyes Fwk0B7jl0q22cTlxji/VcEsHf3Yadm09Joj8GWVPkotFYkEjWkmmqrO1OxkxEqYKeAhQ 6SRKGr3sgTauMPM/U7Rmo0kliW93TfixyKbcPVi3Dro7StRKP67J6IPCBDX6sF5d22Gz bn4Q== X-Gm-Message-State: AOAM532MiwwLhW9luFJ652V2YTeSeZbH3+gc2Vdf/XmOVqBtXUOODx90 I/S+h2kmUbxiX81Mmrvt4Ms= X-Google-Smtp-Source: ABdhPJzMOTtxnVBtJYFETxD9xrGT4o4DfULs9PSItYoSoGFyQeGQPc+agS/dVtKe8a52F5XjCb+cug== X-Received: by 2002:a1c:9852:: with SMTP id a79mr6632045wme.2.1628934512004; Sat, 14 Aug 2021 02:48:32 -0700 (PDT) Original-Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id c15sm3983732wrw.93.2021.08.14.02.48.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Aug 2021 02:48:31 -0700 (PDT) In-Reply-To: <83im08bjc3.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Aug 2021 10:01:48 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211816 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler wrote: >> >=20 >> >> It is important to keep this property since this will preclude many b= ugs >> >> due to string mutation. >> > I am aware of this, of course. Can you give examples of these "many b= ugs"? >> > Perhaps other than the one I already described and addressed? >> No, Jo=C3=A3o, this is not how it goes. I don't have to prove to you th= at >> your idea introduces bugs. You have to show that mutation of the >> completion table strings (which are not supposed to be mutated) will not >> lead to bugs, which are hard to find. > Please calm down, both of you. No one has to prove anything to anyone > here, that's not how Emacs development works. We need to see which > idea is better, and if none is significantly better, we will probably > have both of them living side by side. > > And while asking for an example of potential bugs is reasonable, > asking for a proof that a change will NOT lead to bugs isn't. As far as I remember, I have done the first. I found bugs and addressed them. I cannot _prove_ that my change will not leads to bugs indeed: no-one can with any change. I've just stated repeteadly that I'm not aware of any such bugs. I can understand intuition" for bugs to a certain extent (everyone has intuition), but this intuition must always resolve into actual reality to be useful in the end. > So how > about a couple of examples where having original strings unchanged is > important, which could then be discussed? Good idea, so in the absence of any controlled benchmarks I did some of my own, using the most controlled environment I could devise. I start Emacs like so: ~/Source/Emacs/emacs/src/emacs -Q -f fido-mode -f fido-vertical-mode -l = ~/tmp/benchmark.el ~/tmp/benchmark.el I prime the obarry with lots of symblos to make completion purposedly slow: (require 'cl-lib) (cl-loop repeat 300000 do (intern (symbol-name (gensym)))) I attach the file. Then I try a run of 10 invocations of ;; Press C-u C-x C-e C-m quickly to produce a sample.=20=20 (benchmark-run (completing-read "" obarray)) This, I think, is a good representation of the responsiveness of the completion system. It always prints well after I finish typing, so I don't think I'm inducing any artificial slowdows while it waits for my input. When not measuring quantitatively, I also feel the difference in responsiveness between different approaches. Summarized results with an assortment of Emacs builds. - the current master (254dc6ab4ca8e6a549a795f9eaf45378ce51b61f). 20.25 seconds total =20=20=20 - Applying Daniel's patch over 254dc6. 23.41 seconds total =20=20=20 - The theoretical best situation where we don't highlight in completion-pcm--hilit-commonality (like 254dc6, but just removed the copy-sequence) 10.70 seconds total - Experimental patch published in scratch/icomplete-lazy-highlight-attempt-2 (not finished, still needs a way for frontends to opt into the optimization). 10.80 seconds total I invite you all to reproduce these results. In conclusion, I don't think Daniel's patch is going in the right direction, *performance-wise*, for the kind of responsiveness scenarios that I am concerned with, and which were discussed with Dmitry in bug#48841. It seems to slow down the process by about 10%. Note 1: there may be *other* performance scenarios that I am not aware of, where Daniel's patch excels. I've requested these benchmarks, regrettably without any success. Note 2: doesn't mean that there aren't *other* merits to Daniel's patch, but I have not understood these yet. That is due to the stated fact that the patch is very long, and seems to comprise performance improvements, refactorings, and API redesign. It has no documentation in manual and/or examples on how to use the new API. >> >> Note that your idea also does not address the other issues which are >> >> addressed by my patch. >> >=20 >> > That's for sure. My patch idea addresses only that single problem. >> > I think this is a good property of patches: to solve one thing, not ma= ny. >>=20 >> No, this is not necessarily true. This is only good if the problem is >> solved in a way which is future proof. The idea of mutating the strings >> is a hack and not a solution. > > Just to make sure we are on the same page: adding a text property to a > string doesn't mutate a string. Lisp programs that process these > strings will not necessarily see any difference, and displaying those > strings will also not show any difference if the property is not > related to display. So the assumption that seems to be made here, > that adding a property is the same as mutating a string, is IMO > inaccurate if not incorrect. Yes, in Lisp it is very common to attach a "private" property to an object. If no-one else knows about the existence of that property, then attaching it is not harmful. Generally, of course: there are situations where adding a private property brings side-effects to other parts of the code. But IMO that other code is in the wrong, not the one that adds properties. Also, to be clear, attaching a different property (as in, not 'face') to the completion string is only _one_ of the ways of the ways to bypass copying. According to my measurements, performance doesn't seem to be decided by property attachments, but by copying or not copying of the character data of said strings in completion-pcm--hilit-commonality. Jo=C3=A3o --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=benchmark.el Content-Transfer-Encoding: quoted-printable Content-Description: benchmark.el (require 'cl-lib) ;; Introduce 300 000 new symbols to slow things down. Probably more ;; than most non-Spacemancs people will have :-) (cl-loop repeat 300000 do (intern (symbol-name (gensym)))) (when nil ;; Press C-u C-x C-e C-m quickly to produce a sample (benchmark-run (completing-read "bla" obarray)) ;; scratch/icomplete-lazy-highlight-attempt-2 (dbfe6f72e3608db4488bbc9bbc= 22d876746b1012) (cl-reduce #'+ '((1.060225172 4 0.40529085799999987) (1.084274293 4 0.40401850100000036) (1.075857223 4 0.4066735760000002) (1.096181884 4 0.41024331699999994) (1.090617755 4 0.4027740900000003) (1.092172347 4 0.4073497049999997) (1.064530759 4 0.40525715400000006) (1.088796966 4 0.4075235989999997) (1.052578979 4 0.39851351000000035) (1.0952534230000002 4 0.4396319659999999)) :key #'car);; 10.800488801 ;; Current situation origin/master (254dc6ab4ca8e6a549a795f9eaf45378ce51b= 61f) (cl-reduce #'+ '((2.094681183 15 1.299947048) (2.061771249 14 1.248384553000001) (1.9915545579999998 14 1.1808336689999983) (2.1072676080000003 15 1.2833755230000001) (2.100205698 15 1.2943715630000003) (1.940760815 14 1.1518027680000005) (1.919338815 14 1.127410448) (2.0683418259999997 14 1.272936392) (1.9932618739999999 15 1.1983156959999999) (1.969784269 17 1.140629235)) :key #'car) ;; 20.246967895000004 ;; Daniel's patch from Mon, 12 Jul 2021 21:40:32 +0200 (cl-reduce #'+ '((2.371949053 12 1.0679449390000002) (2.411950542 12 1.0926466229999985) (2.3595232590000004 12 1.0562706020000006) (2.386636212 12 1.0797333340000002) (2.37649102 12 1.0579168220000001) (2.315395413 12 0.9729727209999997) (2.310257558 12 0.9982636050000004) (2.283203076 12 0.9730703639999998) (2.302582002 13 0.9867599240000002) (2.292846619 15 0.9585957429999998)) :key #'car) ;; 23.410834754 ;; Theoretical best (don't care about highlighting, so don't copy) (cl-reduce #'+ '((1.090906703 4 0.40746227999999984) (1.052931397 4 0.4143886020000007) (1.114877434 4 0.42559067599999967) (1.0578293460000001 4 0.40872522) (1.086898854 4 0.4109444489999996) (1.0749850980000002 4 0.41140822900000007) (1.076554257 4 0.4121859250000002) (0.998330274 4 0.3969351310000002) (1.064626675 4 0.4286588339999997) (1.079113392 4 0.44295618700000006)) :key #'car) ;; 10.69705343 ) --=-=-=--