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: Fri, 11 Jun 2021 18:09:04 +0100 Message-ID: <87mtrwuy4v.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> 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="17248"; 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 Fri Jun 11 19:10:24 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 1lrkfo-0004I6-83 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Jun 2021 19:10:24 +0200 Original-Received: from localhost ([::1]:52596 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrkfn-0003PA-7j for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 11 Jun 2021 13:10:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrkfT-0003MX-Al for bug-gnu-emacs@gnu.org; Fri, 11 Jun 2021 13:10:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56550) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lrkfT-0005k4-3G for bug-gnu-emacs@gnu.org; Fri, 11 Jun 2021 13:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lrkfS-00082C-L6 for bug-gnu-emacs@gnu.org; Fri, 11 Jun 2021 13:10: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: Fri, 11 Jun 2021 17:10: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.162343135830827 (code B ref 48841); Fri, 11 Jun 2021 17:10:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 11 Jun 2021 17:09:18 +0000 Original-Received: from localhost ([127.0.0.1]:39863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrkej-000819-Kb for submit@debbugs.gnu.org; Fri, 11 Jun 2021 13:09:18 -0400 Original-Received: from mail-wr1-f45.google.com ([209.85.221.45]:35525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrkeg-00080t-K4 for 48841@debbugs.gnu.org; Fri, 11 Jun 2021 13:09:16 -0400 Original-Received: by mail-wr1-f45.google.com with SMTP id m18so6831653wrv.2 for <48841@debbugs.gnu.org>; Fri, 11 Jun 2021 10:09: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=KP0ZmxByNAbqDds4hVyYLDCrRC7HWkwWxEbZN4U21dE=; b=IxwOq0MqgHBxQIa9Nbvzevl15fMIkC0wd10uHBh9iYhdH1smNwOWi5pTDhSMDY9aEf Um6y3tBm5skqCpw9m3LDV2XyrrlSUfS13WM953qIVOlYvkM9C+wvaIbe37EQC2IbXHCJ 4doUdckmyOaCBFRYp6J1k5xL4yVSgMsEgeuYQFBOC4dXs2QwmI77y389W3EMG5xntKdf fgGUBaFrTxzcHiZp9uSmYg5IGwxaj49xeAJX1EyhPTa5d6hhdcYwMaI6hjxwfWCmJR09 z0dDUlml7nzYU5gIwNrMSyOlSItgarQF268IgjkKZ/SsEMG3ZGiKuhz0dVPgq4oK9O1u pelg== 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=KP0ZmxByNAbqDds4hVyYLDCrRC7HWkwWxEbZN4U21dE=; b=I0ARhDf0rhUUOrdlm0O/rGoNuVotVi4V7+D6nmbio2/xSeYPvDC+yMcoo+RRoiRxnC zZ9bnW3KluM00zkd4YWlxmkIuX61dAI54aNDkIWjPoB6olVFhcyMd3/43d2aYd8uN8RO /88l50R/R2QvAdirLyr7UKBsDqARR5up+LqQoTEz9rsC68HvrWl+DudDZECKYfU6Z9IZ RX44LGsYmu/Hggm2Ci8FXp8SBjPxy/QtyrSyY7ZsrGi7pppmQcCKdvKcESyC43nLmiaz Xygmtnq9FnM0q9W75FMYnw3tocWzSLFwgd28w6OnSKcgfw9UHEz0bS/vgdWbTdjnYJoT 5Vhw== X-Gm-Message-State: AOAM532KVo12RPGxbNKI0ASnQEiZaBPpivBU5rziLXvi7DZU0jWEfoC4 L/5SU+VMQOIDlYTXWV24n2mYyr7jpsg= X-Google-Smtp-Source: ABdhPJzjhQ/Wu+gV0Z6S0LXtfeORPQmffKHmFomPAF7eIOtItueJJDnNxVjJxIA1xgKK4DUD9hUuLg== X-Received: by 2002:a5d:4089:: with SMTP id o9mr5202889wrp.195.1623431348187; Fri, 11 Jun 2021 10:09:08 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id c7sm7775820wrs.23.2021.06.11.10.09.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Jun 2021 10:09:07 -0700 (PDT) In-Reply-To: <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> (Dmitry Gutov's message of "Fri, 11 Jun 2021 05:19:03 +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:208349 Archived-At: Dmitry Gutov writes: > On 07.06.2021 11:52, Jo=C3=A3o T=C3=A1vora wrote: > >> Maybe moving all of them to parameters and return values (making it a >> static function and having the caller manage state) would help, I >> haven't tried that exactly. >> Normally, in those adventures you end up with the same allocations >> somewhere else, and uglier code. But you can try. > > I have it a try, with little success (patch attached, for > posterity). Since there's no multiple value returns in Lisp, I had to > define a container for the three values. And if there were multiple value, you can bet the container for them wouldn't be free ;-) > 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. >> Though given C/C++, a known processor and the right application, >> this will make a world of a difference, and will yield truly "weird" >> results (which arent weird at all after you understand the >> logic). Like, for example a vector being much better at sorted >> insertion than a linked list. (!) Look it up. Bjarne Stroustrup has >> one of those talks. > When you have to do some work, better memory locality can indeed > change a lot. But in this case we have an already computed value > vs. something the code still needs to compute, however fast that is. 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? > Accessing function arguments must be currently much faster than > looking up the current scope defined with 'let'. In a compiled CL system, I would expect the former to use the stack, and the to use the heap, but it wouldn't make any difference in reading the variable's value, I think. But Elisp is byte-compiled, not natively compiled (except for that thing now, haven't tried it), and i don't understand how the byte-compiler chooses byte-codes so all bets are off. > 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? Maybe Stefan knows. Stefan, are you reading this far? 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.=20=20 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.) > 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.=20 But if the speedup is big, I'd revisit the rationale for requiring those copies to be performed in the first place. In my (very brief) testing it doesn't hurt a bit to remove it. > Looking forward for your analysis of fido-vertical-mode's performance > improvement over the "normal" one. Will take a look now. Jo=C3=A3o