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: Sun, 4 Jul 2021 04:53:07 +0300 Message-ID: <526eeb14-31c2-f414-ec44-192180d59164@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> <310ab8d8-2bba-33bb-1aa4-1dc88dcb57d8@yandex.ru> <877disb30s.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="20169"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: Daniel Mendler , 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 Sun Jul 04 03:54:12 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 1lzrKl-0004xq-GT for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Jul 2021 03:54:11 +0200 Original-Received: from localhost ([::1]:44362 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lzrKj-0004ys-TY for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 03 Jul 2021 21:54:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lzrKc-0004yj-Kt for bug-gnu-emacs@gnu.org; Sat, 03 Jul 2021 21:54:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56903) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lzrKc-0004PO-Dx for bug-gnu-emacs@gnu.org; Sat, 03 Jul 2021 21:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lzrKc-0007Sf-C9 for bug-gnu-emacs@gnu.org; Sat, 03 Jul 2021 21:54: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: Sun, 04 Jul 2021 01:54: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.162536360128634 (code B ref 48841); Sun, 04 Jul 2021 01:54:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 4 Jul 2021 01:53:21 +0000 Original-Received: from localhost ([127.0.0.1]:40216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzrJw-0007Rl-PK for submit@debbugs.gnu.org; Sat, 03 Jul 2021 21:53:21 -0400 Original-Received: from mail-wm1-f51.google.com ([209.85.128.51]:54834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzrJr-0007RV-LL for 48841@debbugs.gnu.org; Sat, 03 Jul 2021 21:53:19 -0400 Original-Received: by mail-wm1-f51.google.com with SMTP id l1so8989544wme.4 for <48841@debbugs.gnu.org>; Sat, 03 Jul 2021 18:53:15 -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=ak10DCJqFvpOETh+D4yKpdoeXKfQSRrOzfXtuKu3Ck0=; b=QncbwTJiW+G4C64k0QDa1kNZRL3jPiYmgjOGmJN2Z6dGOy1TktT3Tpz2dfwoxgfz2L Z8HKlvY0V6zufuACkP90eT0/gcbbcJIPjOP0Mqvl/8pqHJXU7mY2zvla57ZeRTLLz2Rt hjqAjfP9mUeL9jPyLHf1DBhxnLN+Jw8iQgOiFaZTttbwFohKmsKDHbJ6o4aAsKAb9/nP gDHwlhPGdCswIvBeZ5UrL04866fXjGZ9AyhUsI+sWLKmyVSfbE781ygF/fXUk863zqnN lIdhnoyWO00bG4KEw5+TcMORvlS4g6GTuQXZiuADL6QY7MLWOQaajHZv9IFHlV6Yvg/Q jEew== 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=ak10DCJqFvpOETh+D4yKpdoeXKfQSRrOzfXtuKu3Ck0=; b=MXgLDNTJzCffcKrM42MMoA49JvgcngWLy0EFS34/09yZfBEQGbbKNwnLCulRPwgC/K h77fP0w5fpNHddH1XWb2JkyzjcVUswK3/CAp5KWmX+t1uUrqsxlWFzDWtSFa9RSS2eZ7 LQF7NeBzE78YOe6HAeea+ICHcuxho4pwXyGMKNr1btvp4abiMzuI5INbYVXkg+qZBEtR wSrgKE53GaG2O6J2iga1YZYyihZxxnECQtIOoUNda/6li4LA4j+PFZlR1++9IIV61DEd Sn4833Detl7q98eBD0YQc/Zj+rLo3AAhon1R2+/CHw7CtsEOtz67ftTeWrw/9+/glTFO Ys4A== X-Gm-Message-State: AOAM530/CpUDoOJ7KQq1Cr88aiRFNacV2ClezdRGjM2BJU32jD4FjBks 95J23Np6HjctRyDdtbRS/4E= X-Google-Smtp-Source: ABdhPJz0+RmXAo8OH5V/i/r6qb5ycSIDuzCnjtSuqaGQUdqbwYsMMz6laWVPYjC9a3fYkt+/M2f4Mw== X-Received: by 2002:a05:600c:3589:: with SMTP id p9mr7611322wmq.182.1625363589800; Sat, 03 Jul 2021 18:53:09 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id c9sm8119719wro.5.2021.07.03.18.53.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Jul 2021 18:53:09 -0700 (PDT) In-Reply-To: <877disb30s.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:209375 Archived-At: On 18.06.2021 00:21, João Távora wrote: > Dmitry Gutov writes: > >>>> 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. > > Oh, you meant the The Big Redesign? I'm a fan of that too, not only > here but constantly, everywhere... That indeed means simpler resulting > code in abstract. Problem is that also means different resulting code > to different people. But is definitely doable. I meant a particular change (not modifying the strings at all in advance) which would be bigger and indeed might better fit The Big Redesign. >>>> 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. > > OK. I can live with that rationale. So what are the places to touch > that "we" control? > > - icomplete.el? for fido-mode & friends > - minibuffer.el, for the *Completions* buffer > - company.el > - Any notable others? corfu, consult, etc? Probably Ivy too. All of these are in GNU ELPA. BTW, I think Daniel had some ideas about applying the face property lazily as well. I can't find the particular discussion now, but perhaps he can add to this discussion as well. >>> ;; 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. > > Yes, this is a big performance bottleneck. But i wonder if tweaking GC > parameter would help here. I know nothing of Emacs GC parameters. I think the current understanding that by raising gc-cons-threshold we exchange the number of GC pauses for larger latencies. I suppose one could tune that value to a particular workload such that the 4 GCs in a row that I had will turn into just one (and thus save on re-scanning the heap 3 times), but data sets change.