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: Mon, 7 Jun 2021 03:11:41 +0300 Message-ID: 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> 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="36173"; 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 Mon Jun 07 04:06:13 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 1lq4ea-0009FV-Ir for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 07 Jun 2021 04:06:12 +0200 Original-Received: from localhost ([::1]:45904 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lq4eZ-0006cY-Im for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Jun 2021 22:06:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58542) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lq4eQ-0006cF-9d for bug-gnu-emacs@gnu.org; Sun, 06 Jun 2021 22:06:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42677) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lq4eQ-0000M2-2b for bug-gnu-emacs@gnu.org; Sun, 06 Jun 2021 22:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lq4eQ-0000Xt-7d for bug-gnu-emacs@gnu.org; Sun, 06 Jun 2021 22:06: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: Mon, 07 Jun 2021 02:06: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.16230315512079 (code B ref 48841); Mon, 07 Jun 2021 02:06:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 7 Jun 2021 02:05:51 +0000 Original-Received: from localhost ([127.0.0.1]:54223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq4eF-0000XT-8L for submit@debbugs.gnu.org; Sun, 06 Jun 2021 22:05:51 -0400 Original-Received: from mail-wm1-f54.google.com ([209.85.128.54]:53944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq4eA-0000XD-RK for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 22:05:49 -0400 Original-Received: by mail-wm1-f54.google.com with SMTP id h3so8977789wmq.3 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 19:05:46 -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=Qh3fWlA8R0G+DuOtNzp724Hh4UwP1QBX9ubO7NjSys0=; b=GYKFAoMh0ZvWXWzJI0ATJBJXAUEl/9OqRMasjnjOYHn/AqbPVxMLvDFP/qnqLaOrSg V8NqRM07LJvI7+TXXEAZjyInWDZCF+7wh25q27F8z6C8FRqAV/SJaNnprxiR9CPSHQve eq2o7QZHoz27wX+Nv9RvH+kH0HnBvSbbWB+5ASA3FISYXYGGXUUy+2TRnSLYhdA3kFNC xCzkhTQf6rQYnkunZzM7Mse5y6bB6ebV0rkVDblUpaOgfwo2UovHGMKazqsaRjyUeyHu sFTx8uKCrkECjL86l4mM/55wYAsUcn+PpVdFPLkRwQMkfalGoCnQsPaTtW3ssfvDXhCb I0xw== 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=Qh3fWlA8R0G+DuOtNzp724Hh4UwP1QBX9ubO7NjSys0=; b=RYEWqH7Y3jFfP0M2mElva+HsrjWsaGFUJKUV1g/vC0h5GxHAZcHIxMuEj7UsTiiM8u m3j0j4zV5XqUQgWkSjzOcHsgusziGuBHgOZsJbxOiG02ukX90sEMWcj/ni+061VaaKyg MwZikZvCc3hCx0F+MdszKGen5NStSMvKiVhnI9U6nU9vMwC5xmSeh9azm+2iDmdkrJJx vpRSwjZtbx8A/KnLM2MER0hd+L14xl+6/QSz18rDolO6BqPqFIz1TkTu38mG5llxLTWC qRDd8JONCcM47w+yq3uFIbeDV81oGVK01TaKbiHfOEaU164qhur9WdxgSS3FkB+/9K4O tvZg== X-Gm-Message-State: AOAM53342/Igw7mzStdvW2dDEFZ2/TKKgKeBC+l98PWrqhe/+DoAT9Jn kYJk+yuvoVSyhcbSZM07SO+hEAPl71E= X-Google-Smtp-Source: ABdhPJxUM1oSG+JRblYXYWljouB1tbxWOZH7vDC4T/DMOyTY/hzgXS1Wm10EKmS/kOpfMDx6jEP84g== X-Received: by 2002:a1c:740b:: with SMTP id p11mr13978927wmc.94.1623024703737; Sun, 06 Jun 2021 17:11:43 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id 89sm14715741wri.94.2021.06.06.17.11.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Jun 2021 17:11:43 -0700 (PDT) In-Reply-To: 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:208172 Archived-At: On 07.06.2021 02:49, João Távora wrote: > Same result, indeed. We should note, though, that > completion-pcm--hilit-commonality has some steps that were added > together with the 'flex' style, for it to work. > > > But nothing algorithmically aberrant, I think. Just some stuff adding work to GC, I think. > By the way, I think you should be running benchmarks multiple times to > get times in the seconds range, and reduce noise. Multiple levels of CPU > cache and other factors like temp thottling may skew results when > running just one time. Yeah, I repeat the action with each version for like a few dozen times, until I see the numbers stabilize, or just take the average. > Tried binding gc-cons-threshold to a high value, and even galling > garbage-collect-maybe (or not): that speeds it up, but adds some > unpredictable GC pauses later (though it would be nice to be able to > consolidate the pauses into one collection pass). > > > Maybe in Elisp that's a good idea, in other lisps and other languages, > second-guessing the GC is a bad idea. I hear ours is so basic that > indeed it might be reasonable. I never get good results with that. > Long story short, the patch I just installed, to reuse the match data, > brings the runtime down to > >    Elapsed time: 0.066388s (0.050087s in 3 GCs) > > > That's nice! but are you sure you're not seeing noise, too? Pretty sure. > Tried other things like moving the update-score-and-face lambda out of > the mapcar loop - that didn't move a needle. > > > If a lambda is non capturing of stuff inside the loop, only one copy of > it is ever made, I think. So it doesn't suprise me. update-score-and-face references both variables in its closest binding form (score-numerator, score-denominator) and the parameter of its containing lambda (str). 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. > And a weird part: replacing all repeated (length str) calls with a > reference to an existing local binding makes it *slower* (back to the > original performance). > > > Might be noise, or you might be thrashing of CPU caches, who knows? If > the string length is on the same cache line as the contents of the > string you're reading, then evicting that to go read the value of a > boxed integer somewhere radically different is slow. But the string value is boxed as well, right? So the code needs to follow one indirection either way. Perhaps there's also overhead in looking up the lexical scope. I also tried using the new-and-shiny length> and length=. This simply made no measurable difference. > Just speculation of > course. Might just be noise or something else entirely. This is highly reproducible. On my machine, at least. Given how weird it is, I wouldn't just write about it without recompiling, restarting Emacs and measuring the scenario several times, with different versions of code.