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: Sat, 12 Jun 2021 01:34:58 +0300 Message-ID: <2234991b-c2e0-81e3-c1ef-b1d94d35a728@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> 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="25790"; 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 Sat Jun 12 00:36: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 1lrpl4-0006Zh-UI for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Jun 2021 00:36:11 +0200 Original-Received: from localhost ([::1]:44834 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrpl3-0001dy-0C for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Jun 2021 18:36:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrpkv-0001dg-TO for bug-gnu-emacs@gnu.org; Fri, 11 Jun 2021 18:36:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56737) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lrpkv-0003J7-LG for bug-gnu-emacs@gnu.org; Fri, 11 Jun 2021 18:36:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lrpkv-0003RV-Io for bug-gnu-emacs@gnu.org; Fri, 11 Jun 2021 18:36:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jun 2021 22:36: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.162345091213172 (code B ref 48841); Fri, 11 Jun 2021 22:36:01 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 11 Jun 2021 22:35:12 +0000 Original-Received: from localhost ([127.0.0.1]:40050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrpk7-0003QO-Op for submit@debbugs.gnu.org; Fri, 11 Jun 2021 18:35:12 -0400 Original-Received: from mail-wr1-f49.google.com ([209.85.221.49]:34523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrpk2-0003Pu-SZ for 48841@debbugs.gnu.org; Fri, 11 Jun 2021 18:35:10 -0400 Original-Received: by mail-wr1-f49.google.com with SMTP id q5so7537744wrm.1 for <48841@debbugs.gnu.org>; Fri, 11 Jun 2021 15:35:06 -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=kspJlPrvXJdmD+apw3Q6OZ2yPlWxQjMirT12OsZA0hg=; b=OQGl49CdAH6Go60KdmG6PnK27eIDYFNiR5EBaZTltwl/udUo3kgG3y5DrmOvmXWTge 9cQtzvfdTNC9pCagEqhXFcnTDUyEA1ViEH7DWzWLwT0fcLpeJRIJlwSbFpSzK80jq0xP 21hvlFkbJi/FjWORY4VRRlhGg9F0atUccoD5ghP9BGninwuPDDUdBS3nu+/H++sJtV42 aaqjTus+CuBgVXhx3ZvYCUs+2m/BKz4DPMQpMv2oNSe5whkYeXmCWL9ISihmMlpKYcmf Pmjx6K+Y6uANtbWYXSKvqutkAYR0VtniiQ+yVo6nuRYKiQx8vW37PurymUZ+V2OLqs+X GmUw== 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=kspJlPrvXJdmD+apw3Q6OZ2yPlWxQjMirT12OsZA0hg=; b=bnJK1rJqRKcIXs1SqTSGEt2MHggY5YCmvP8vg1XEIBlr3yxJBsc12+M5GARI8gDfWN 5KLJmCiAxHesesj9tcEroGOj+HfLHbyMTDfRBVLVAkUEUlz8U07k0gHxAmvs8yi8iEUu U+TciY355IzMprIrT+lOkxV8nj8ZSRv6yYwoMXFSn6p6sPEAuhSq0/t5yu4R4lPLJRB2 9D19WvUmy9asg+1IDNbnprannSN3WqHIzvUpVstBfyzslEWwAPRttaiLfoeI6g5PHmIO wcVuTI+uVGFLxwx2Ucm7Ohuet7Eu0gjq0efjOmz9VHgDHWA/exVszTgrNSUj7JtglSaw TAQA== X-Gm-Message-State: AOAM533oFDg0yGBdEUyjl8pJJe2df+nyB/1OmU+x0oGUWAOptMEPkxJS YloXY/Fgx9K/Wri40mzZb56UKCzIVMw= X-Google-Smtp-Source: ABdhPJyTIHSjLiq2jPnVEdwKGvMLvCT0Yf/NlWk8zeOuCWYAgzufkmGYgsLgKEmzFHNyK5H3/DPPag== X-Received: by 2002:adf:fc90:: with SMTP id g16mr6234159wrr.183.1623450900970; Fri, 11 Jun 2021 15:35:00 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b188sm17934050wmh.18.2021.06.11.15.34.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Jun 2021 15:35:00 -0700 (PDT) In-Reply-To: <87mtrwuy4v.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:208358 Archived-At: On 11.06.2021 20:09, João Távora wrote: >> The performance is basically the same, which seems to indicate that >> either Elisp has to allocate very little for a compiled lambda code, >> or it's optimized out (which would also make sense: the only thing >> necessary for it is a new container for the current scope). > > Which lambda are we talking about? Is it ` update-score-and-face`? If > so, I would guess that the capture of `score-denominator` is what takes > space, and that space is no bigger than another variable in that let > scope. Yes, that one. > But `length` of a string, in any sane string implementation, _is_ > accessing "an already computed value". Which likely lives just besides > the data. In Emacs, it seems to be two pointers (8 bytes) apart from > the data. In a system with 64bytes of L1/2/3 cache it still > theoretically makes up to 52 bytes come in "for free" after you read the > length. But to be honest I tried a bit and haven't come up with > benchmarks to help confirm -- or help dispel -- this theory. Maybe you > can distill your "weird" experiment down to a code snippet? I've tried reproducing the effect with a small snippet, and failed. :-( >> Anyway, looking at what else could be removed, now that the extra >> allocation in 'match-data' is gone, what really speeds it up 2x-11x >> (depending on whether GC kicks in, but it more often doesn't), is >> commenting out the line: >> >> (setq str (copy-sequence str)) >> >> So if it were possible to rearrange completion-pcm--hilit-commonality >> not to have to modify the strings (probably removing the function >> altogether?), that would improve the potential performance of c-a-p-f >> quite a bit, for fido-mode and other frontends (depending on how much >> overhead the other layers add). > > 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?) > 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? > This technique appears to be slightly simpler than using the hash-table > indirection you propose (we would need something like that if, for some > reason, we absolutely could not touch the string's property list.) I disagree it's a simpler technique, but it would indeed be a simpler change, based on the current implementation. >> Anyway, these are musing for the much-discussed future iteration of >> the API. With the current version, and tied by backward compatibility, > > Maybe I'm missing something, but I don't see why my above idea requires > changing _that_ much of the API (a bit would change yes). It's a matter > of letting frontends opt-out of the current readily-available > face-propertized completions and opt-into a display-time facility that > does this propertization. Even your version is a breaking enough change to be a pain, but possibly not beneficial enough to bother all consumers with, until we also add some more awaited features, I guess. But I don't mind it myself, and happy to update Company. Either way it's a step forward. > 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. > In my (very brief) testing > it doesn't hurt a bit to remove it. Same. But it likely depends on where the strings came from. In the most usual case, of course, they are created at runtime.