From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Date: Thu, 17 Jun 2021 05:36:41 +0300 Message-ID: <310ab8d8-2bba-33bb-1aa4-1dc88dcb57d8@yandex.ru> 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> <87v96hu845.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15809"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Cc: Stefan Monnier , 48841@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 17 04:37:11 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 1lthu1-0003vs-ID for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Jun 2021 04:37:09 +0200 Original-Received: from localhost ([::1]:51056 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lthu0-0007Db-9L for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Jun 2021 22:37:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34844) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lthtu-0007DS-Kw for bug-gnu-emacs@gnu.org; Wed, 16 Jun 2021 22:37:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42028) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lthtu-0004eZ-Bv for bug-gnu-emacs@gnu.org; Wed, 16 Jun 2021 22:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lthtu-0004Xp-6Q for bug-gnu-emacs@gnu.org; Wed, 16 Jun 2021 22:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jun 2021 02:37: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.162389741117450 (code B ref 48841); Thu, 17 Jun 2021 02:37:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 17 Jun 2021 02:36:51 +0000 Original-Received: from localhost ([127.0.0.1]:53574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lthti-0004XN-F7 for submit@debbugs.gnu.org; Wed, 16 Jun 2021 22:36:50 -0400 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:43829) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lthtg-0004X9-SD for 48841@debbugs.gnu.org; Wed, 16 Jun 2021 22:36:49 -0400 Original-Received: by mail-wr1-f46.google.com with SMTP id r9so4817595wrz.10 for <48841@debbugs.gnu.org>; Wed, 16 Jun 2021 19:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5/nwz58rPyP5tD1djpKtzlcG+IBLdenjg0bZJ54OcBI=; b=TdtYRU78cdhYKejiqjW2w0qlVG7Wuj2JuXxQ8eNIvHMqTvkFwHL0rzdb4TVcLcIZ8U ka11ghSUO0KIEi0o1lGpRBN45r9blFn/h7M5yWROLqa2i38W4elECGF59ebWqpw+iXEX 38Ef4HHh/RsHM8SZNHpOH/3lfrBbsfK28fmQRNy9S7Jx/GTj8WnG6zLwQx87Q6UjLR6n kh6hV4QQLOfUotdlwZpH5zbF3yHfpE0ijj29HQsxgsLrZZhlWnYM+AydZfISRYHK1DTi BsZKLBWHCBYqHjS5RdjCHTAQfCmh0+62s2AvtWRZdMBlUfbvKju2r6j/9NWRezTHB05J aUqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5/nwz58rPyP5tD1djpKtzlcG+IBLdenjg0bZJ54OcBI=; b=FC4SKm88M6ingqrY5L56b2Ya/I8TEqpIgnfrnnM9thOImNqXvma1NYpPMDVKzmMrlR Wa7Lf7ifq4Gmmr9nCOAl33vgejronsCUWsWl9Ms5nT+ZNN2EvomSHW1/KloEyXNBLaaA X5VLOlp9MaQWFv1fmNmKltf2zSHRlfkI+t0Cjckc+YvurqCtDgQ6JV1X2gYIL7aCB4P2 Z8PtqhRPiD/kMcEagl9By9cHM0JiNdfExVyPJ8rrBgRZvcTIzuSgyyTmPDLLhK4jlP/+ PVvPqTNNICXUeCUNvcnz/CR26jZ+pxEZH5hBE5kGqHTiako6C9bwVB7YrqvlI1e5oSu1 6AZg== X-Gm-Message-State: AOAM5313eIU2QHvGvdGFinvJGczNbDo0kvHcotwgcr4+nFDmsE+q3smT hYR88FeuYgnakL7x1by+swrxwzpUcNk= X-Google-Smtp-Source: ABdhPJxX52+9RMaEqKt+s7OWx7hN+0gBRhVSFmqOvsOmEJ+O4L2v96WZk0WqSfNKWIAi5aXcgpjQWg== X-Received: by 2002:adf:e485:: with SMTP id i5mr2645196wrm.214.1623897402824; Wed, 16 Jun 2021 19:36:42 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j5sm3721775wro.73.2021.06.16.19.36.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 19:36:42 -0700 (PDT) In-Reply-To: <87v96hu845.fsf@gmail.com> Content-Language: en-US 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:208653 Archived-At: On 13.06.2021 17:55, João Távora wrote: > 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. That's also an example of correctness problem, just the more obvious kind. It probably happens in a number of situations, e.g. all (?) uses of completion-table-with-cache. > But maybe that's a question of removing the propertization when the > pattern is empty? I'll try later. That must add some performance penalty as well, for extra mutation. And wouldn't cover some potential other uses of the same set of strings. In IMenu, maybe? The latter is hypothetical, of course. >> 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? It wouldn't help. It would do the opposite: basically forbid the approach you suggest, mutation without copying. >> 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 :-) One is simpler diff, another is simpler resulting code. Both have their upsides. >> 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." Since all other users are third-party (and thus have short release cycles), it shouldn't be too much of a problem. Some highlighting code would start to fail, but probably without disastrous results. And then people will issue updates to look for some new property when the old expected ones are all missing. >>> 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) > > ;; 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) > > ;; without copy. Huge speedup. > (0.79817337 1 0.4526993239999797) > (0.8231736510000001 1 0.4752496449999626) > (0.719004478 1 0.4016016420000028) Even better. My current session has 37559 symbols, so it's somewhere in the middle.