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: fido-mode is slower than ido-mode with similar settings Date: Sun, 13 Jun 2021 15:55:38 +0100 Message-ID: <87v96hu845.fsf@gmail.com> References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <87mtrwuy4v.fsf@gmail.com> <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33520"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Stefan Monnier , 48841@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 13 16:56:10 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 1lsRWy-0008O2-As for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Jun 2021 16:56:08 +0200 Original-Received: from localhost ([::1]:53420 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lsRWx-0006sd-4z for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 13 Jun 2021 10:56:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lsRWr-0006sS-So for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2021 10:56:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60890) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lsRWr-0003gT-LU for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2021 10:56:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lsRWr-0005wj-Lv for bug-gnu-emacs@gnu.org; Sun, 13 Jun 2021 10:56:01 -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: Sun, 13 Jun 2021 14:56:01 +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.162359614822834 (code B ref 48841); Sun, 13 Jun 2021 14:56:01 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 13 Jun 2021 14:55:48 +0000 Original-Received: from localhost ([127.0.0.1]:44203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsRWe-0005wE-Bq for submit@debbugs.gnu.org; Sun, 13 Jun 2021 10:55:48 -0400 Original-Received: from mail-wm1-f50.google.com ([209.85.128.50]:38592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsRWc-0005w1-BN for 48841@debbugs.gnu.org; Sun, 13 Jun 2021 10:55:47 -0400 Original-Received: by mail-wm1-f50.google.com with SMTP id t4-20020a1c77040000b029019d22d84ebdso11327636wmi.3 for <48841@debbugs.gnu.org>; Sun, 13 Jun 2021 07:55:46 -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=MOKm0vFEiIKTy8tfYfBBuh3DzPkLjD/0sBF+RuwSlGQ=; b=XbQbwz9ZVWYNSf35VBpNKFggP9GmcZCUTzqX3FXnoubXnzc4bya5w92Px0GGHycnIu OjbtKi7ZcgFShehVN7DmlbYg6qKPIhkFFbOWuYvMEA1Uqw3EWYkbPQ18k327cOOxx0By pfO8UXRpbxA9lk3TVvR/bWSSdvAy0Te4/TYOETu4KvCMjDdRoHg+lgJjgdH0k/6TamSW cmQTF4IJFS9UbMXtoSrOFiCuc8SVMasyHW2Rs7BAsr86Y5pGurPPjuhMaFZcpNlW683L kRO0BybvgX3Rwa429I9FqA1+FzNFh9ml4cmHfXEhATB/f1EhMn7b2e7vMgaVfwGLaCC5 1XQQ== 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=MOKm0vFEiIKTy8tfYfBBuh3DzPkLjD/0sBF+RuwSlGQ=; b=duEP5aILDEpcq4N8uJ/+fkv1eU09qmmR7tAWAZ14bVriOxFx2klrLhYHr4N65WeR6A 4GYkjb3Rrl5ykplWnY6op561psoEIorprlWuJpVdpDOMs3i2cHMj9wcEgSH129QFdsaj DYHYgiv19S+7Hc2OKHRFkz/hs3KgjGMGmypz/Xk+uapVVPhmqULsCXjPQj3UTxyHPE5K 1E5Lc9qFZeFpjHrWL+8ierfgsJOOz0/OC0ZTwrE4v3H5h9fUk6c7TmNZb+3hmKLZbXlM EUvoHtjg+Q6wGR1xk9yN7swvs51tAdU2uHfDS9vQqWzstK8XVg2vIJoxO09pk4aRV96N isBA== X-Gm-Message-State: AOAM531MQqDP5cGpQDoa27ArqAJJP5NTnbnaddHa2opJS0xGDuaSVL9C tRlnnNDSZDS9zLaScOLnFwk2sAHenEg= X-Google-Smtp-Source: ABdhPJzKOLtzHnREKmS+Ci0XpPwJhYMs++RDyTi9nnlEYxUKJLufD+HFAhhCOdeQtxwHfjZw4swBxw== X-Received: by 2002:a7b:c2f0:: with SMTP id e16mr12056591wmk.136.1623596140035; Sun, 13 Jun 2021 07:55:40 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id q19sm9239717wmf.22.2021.06.13.07.55.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Jun 2021 07:55:39 -0700 (PDT) In-Reply-To: <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> (Dmitry Gutov's message of "Sat, 12 Jun 2021 01:34:58 +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:208447 Archived-At: Dmitry Gutov writes: >> Very interesting. I don't know what the matter is with modifying >> the >> string itself. Is it because we want to protect its 'face' property? >> Maybe, but what's the harm in chaning it? > > I imagine it's just a "correctness" thing. Text properties are part of > the string's identity. We add text properties, so we make a copy > because we don't own the original list (it might be saved to some > constant and also used for, I don't know, IMenu items?) I just confirmed it's not for correctness. If one foregoes the copy, in fido-mode a C-h f followed by some input followed by C-g and an M-x and no input (empty pattern) will show interesting results, i.e. a list of propertized strings when nothing should be propertized. But maybe that's a question of removing the propertization when the pattern is empty? I'll try later. >> If we do want to protect the shared 'face' property -- and only 'face' >> -- then we could very add some other property about face that the >> frontend could read "just in time" before it itself makes a copy of the >> string to display to the user. > > Yes, it's an option (though a less elegant one): apply some namespaced > text properties with the necessary data. And then we'd also be able to > fontify "just in time". > > Do we have any "frozen strings" in Emacs, which absolutely could not > be modified? Do we plan to? Immutable strings? And error when one tries to? Or just ignore the modification? And how would that help here? > I disagree it's a simpler technique, but it would indeed be a simpler > change, based on the current implementation. simpler means simpler in my book :-) > But I don't mind it myself, and happy to update Company. Either way > it's a step forward. If Company and fido-mode and a couple more outside the core/Elpa are all that's needed, it's probably warranted. But there are so many frontends right now, I don't know... We'd need some "opt into the optimization", I think." >> But if the speedup is big, I'd revisit the rationale for requiring those >> copies to be performed in the first place. > > With fido-vertical-mode, and with that particular input, it's > > Elapsed time: 0.130773s (0.031547s in 1 GCs) > > without copy-sequence, and > > Elapsed time: 0.169842s (0.069740s in 4 GCs) > > with it. Not game changing, but definitely measurable. I don't have these results. I tried the previous experiment: ;; C-u C-x C-e C-m in quick succession (benchmark-run (completing-read "bla" obarray)) And turned icomplete.el's while-no-input into a progn. In an Emacs -Q where (length (all-completions "" obarray)) is about 20000. ;; with copy (0.39647753 6 0.22811240199999983) (0.431950471 7 0.263988651) (0.451116177 6 0.2249686070000001) =20=20=20=20 ;; without copy, small but measurable speedup (0.29890632 2 0.08419541699999966) (0.293501099 2 0.08622194699999985) (0.306566633 3 0.0853211100000002) In a loaded Emacs where (length (all-completions "" obarray)) is 64554 ;; with copy (2.869362171 6 2.3882547280000495) (2.909661303 6 2.4209153659999743) (2.845522439 6 2.3638140250000106) =20=20=20=20 ;; without copy. Huge speedup. (0.79817337 1 0.4526993239999797) (0.8231736510000001 1 0.4752496449999626) (0.719004478 1 0.4016016420000028) Jo=C3=A3o