From unknown Sun Jun 15 08:42:07 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#45379 <45379@debbugs.gnu.org> To: bug#45379 <45379@debbugs.gnu.org> Subject: Status: 28.0.50; Degraded Performance of describe-buffer-bindings Reply-To: bug#45379 <45379@debbugs.gnu.org> Date: Sun, 15 Jun 2025 15:42:07 +0000 retitle 45379 28.0.50; Degraded Performance of describe-buffer-bindings reassign 45379 emacs submitter 45379 styang@fastmail.com severity 45379 normal tag 45379 fixed confirmed patch thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 23 01:02:03 2020 Received: (at submit) by debbugs.gnu.org; 23 Dec 2020 06:02:04 +0000 Received: from localhost ([127.0.0.1]:51534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1krxDn-0002E4-L5 for submit@debbugs.gnu.org; Wed, 23 Dec 2020 01:02:03 -0500 Received: from lists.gnu.org ([209.51.188.17]:44172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1krxDl-0002Cj-VA for submit@debbugs.gnu.org; Wed, 23 Dec 2020 01:02:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39120) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1krxDl-0008Ms-I9 for bug-gnu-emacs@gnu.org; Wed, 23 Dec 2020 01:02:01 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:48017) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1krxDi-0000F0-QP for bug-gnu-emacs@gnu.org; Wed, 23 Dec 2020 01:02:00 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 75B8EC79 for ; Wed, 23 Dec 2020 01:01:55 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 23 Dec 2020 01:01:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=fm1; bh=/unyVMCE5hMYk2P4bHU7Z9Pxsg BByBWt5AvpENykSGo=; b=mXlQYG4lkdGJLvPvqRRke37elxHpcUau04jp1FhG2r 0wm66rivHwuh/mmvGCg8hfZ9wjNZsxwAlOrjlb7l2NddPQv83oXjhu/gHp7bUvHh OJQ9E3g1YQw7uMUO3dD/nKW2BjWs8WHeXxb8Myfjsf+Ah3DWxM1pQRAUsJ3iuSXk ryDKjLpJky9EEdqpvwxUGU9i48MDv9qRkGltAYbwnOWHAUXBwea5mmI6f5pV/O7U hU/SftKey6EvlHPYgqvFUgcxpxBQoQpRLW8LCPj+PS3lvVmXe0CXAxcTploDqnNy hoyZ6IdwxpQXM3p6tnCxpXVGFbCtl/ZiPYXZWgyP7R7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=/unyVM CE5hMYk2P4bHU7Z9PxsgBByBWt5AvpENykSGo=; b=NIID9JY5zErXq0CmNnhLij Uum4jaAUfjFyUz2oUe4upLw/Iyt/D+dZFXC2SUkVSCbcjZOZUZZCqnFiJ4lCE7QE eC/TA0tjrgY2E/a8Hf0c1HDRnyjapLdns3xBrYNTMiNjxVyfxAmLIuPHg4Ti5HSc Q+8JRRBTmsgBfGq1Kut+S3roXjFUNz2Igmerx5+seLpU3NuUAsLkVdS1ZBv+wcCY EAjmvlJQIOngKX+j5Efby3CTijNm4TFVS3cV/dTDYv8OEE8A21UMmpY+Dyso15kL W0m0bovFs749V0eUkG+/O4jMxzEbD5IAdYY1H1g3XlJK9o9AbPfNOVGp8JUXwz8Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtiedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkgggtgfesthhqredttd dtjeenucfhrhhomhepshhthigrnhhgsehfrghsthhmrghilhdrtghomhenucggtffrrght thgvrhhnpedtveeufeehleekheeuudevvedvhfeiveeuheevjeeileelhffgkedvjeelke dutdenucfkphepjeefrddvtdekrddugeelrdekfeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehsthihrghnghesfhgrshhtmhgrihhlrdgtoh hm X-ME-Proxy: Received: from localhost (c-73-208-149-83.hsd1.il.comcast.net [73.208.149.83]) by mail.messagingengine.com (Postfix) with ESMTPA id AA46724005B for ; Wed, 23 Dec 2020 01:01:54 -0500 (EST) From: styang@fastmail.com To: bug-gnu-emacs@gnu.org Subject: 28.0.50; Degraded Performance of describe-buffer-bindings Date: Wed, 23 Dec 2020 00:01:53 -0600 Message-ID: <87a6u5m566.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=64.147.123.24; envelope-from=styang@fastmail.com; helo=wout1-smtp.messagingengine.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) `describe-buffer-bindings` has become significantly slower since the following commit a649034336 * bad Don't show key ranges if shadowed by different commands This also makes `describe-bindings` and anything depending on it hardly usable. For me, it takes about 2 seconds on vanilla Emacs in an org-mode buffer, and a few minutes on my Emacs configuration (was almost instant before the offending commit). --=20 Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD student Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail(old): yangsheng6810@gmail.com From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 08 11:48:16 2021 Received: (at 45379) by debbugs.gnu.org; 8 Jan 2021 16:48:16 +0000 Received: from localhost ([127.0.0.1]:50516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxuvw-0004FS-47 for submit@debbugs.gnu.org; Fri, 08 Jan 2021 11:48:16 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:59911) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxuvu-0004FD-2C for 45379@debbugs.gnu.org; Fri, 08 Jan 2021 11:48:15 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E63055C029C; Fri, 8 Jan 2021 11:48:08 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Fri, 08 Jan 2021 11:48:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:date:from:to:cc:subject:content-type; s= fm1; bh=hQuEWtpxggdmb923axQ7NT+oQb2Vz0PEo1Tk7xP5bT0=; b=RPmXmvsJ wRtW1v+2RrQ+wYznJoxakQEzScr+zWAmNSl+e1YSELMTqfARks/aoKDzQgUq7Dsm W9qBP0+uTXJmXc/KtRPdxyn6mPWWswL9+nhzW/pr8NiQt5lJ+gKc5x3zrfzDCgfw EPoJ7F6ap+stXS6wAc5wlK4NSAZ9J2SgpdDGiKRe6S44DVplu3oDyUTZTgQoQDcd lGpLvrUGem/LOZReipdgIdjCjiNE2igFfzSZPWh3jaW88KlBitvpX5al6hZvkvWS b19NiEGvBeg8TSx+jnILKO5kxIobXpJQmE53eyuHdrYNxPLSmxfF9uJ2M0SSBbCZ s/eIFPHJQVkNDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=hQuEWtpxggdmb923axQ7NT+oQb2Vz 0PEo1Tk7xP5bT0=; b=oC61bwlNIm8V0+qE/B4VASumzW0feYsO8oJpIVCsFKoDr XE/L5VhY3YL1a4U1A77CjJrRmJ+6VtpZ8rgkN1i8HxPHlW4jvuADY7jeqPHahsF2 dShuzIKqy7QZzMmJBjU7q4J/GqtkZrkfkXNadSx+RDzQwVFed1M+AYgZJyQ/XET2 JuemaFUD573RdzlKXNnn2jW7IyYHLffXsfrT6oPko1Cg2SYt2NZxHHCjByzxTyv4 pwtrhi3AgePTRGxf4OkLej5hH1AnAWvEgC3y1ZheD9z3q7o3fJ03ani6bt7GkqXW aM9TGR515h8T8KTyL5YzLahQ4uOTvzAtBgQ5AfFqA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeghedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfuhhgvnhhg ucgjrghnghdfuceoshhthigrnhhgsehfrghsthhmrghilhdrtghomheqnecuggftrfgrth htvghrnhepjeevvdehkedugefgudfhudeiieelvdefvdekheeludeuhfelueeghedtkeeu teeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsh hthigrnhhgsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 66018E00DC; Fri, 8 Jan 2021 11:48:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> Date: Fri, 08 Jan 2021 10:47:47 -0600 From: "Sheng Yang" To: "Juri Linkov" Subject: Re: 28.0.50; Degraded Performance of describe-buffer-bindings Content-Type: multipart/alternative; boundary=68704380d348437199d88f5a9068e7db X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Juri, I recently came across a regression of performance in Emacs for describe bindings, which I have reported as bug#45379. After bisection, the offending seems to be a commit a649034336 you pushed in Nove [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (styang[at]fastmail.com) 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [66.111.4.29 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [66.111.4.29 listed in list.dnswl.org] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 1.0 HEXHASH_WORD Multiple instances of word + hexadecimal hash 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 45379 Cc: Stephen Berman , Stefan Kangas , martin rudalics , Stefan Monnier , Eli Zaretskii , 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --68704380d348437199d88f5a9068e7db Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Juri, I recently came across a regression of performance in Emacs for describe= bindings, which I have reported as bug#45379. After bisection, the offe= nding seems to be a commit a649034336 you pushed in November 2020, to fi= x bug#5423. Since I have received no reply after bug#45379 was reported = (more than 2 weeks), I guess it's better to contact you and cc every par= ticipants of bug#5423. I am including the description of the bug report = here for your convenience. > `describe-buffer-bindings` has become significantly slower since the following commit a649034336 * bad Don't show key ranges if shadowed by different commands= This also makes `describe-bindings` and anything depending on it hardly usable. For me, it takes about 2 seconds on vanilla Emacs in an org-mode= buffer, and a few minutes on my Emacs configuration (was almost instant before the offending commit). >=20 Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD candidate Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --68704380d348437199d88f5a9068e7db Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Juri,

I recently came across a regression of performanc= e in Emacs for describe bindings, which I have reported as bug#45379. Af= ter bisection, the offending seems to be a commit a649034336 you pushed = in November 2020, to fix bug#5423. Since I have received no reply after = bug#45379 was reported (more than 2 weeks), I guess it's better to conta= ct you and cc every participants of bug#5423. I am including the descrip= tion of the bug report here for your convenience.

`describe-buffer-bind=
ings` has become significantly slower since the
following commit

a649034336 * bad Don't show key ranges if shadowed by different commands=


This also makes `describe-bindings` and anything depending on it hardly
usable. For me, it takes about 2 seconds on vanilla Emacs in an org-mode=

buffer, and a few minutes on my Emacs configuration (was almost instant
before the offending commit).

=
Sheng Yang(=E6= =9D=A8=E5=9C=A3), PhD candidate
Comput= er Science Department
University of Ma= ryland, College Park
E-mail: styang@fastmail.com
E-mail (old but still used): yangsheng6810@gmail.com


--68704380d348437199d88f5a9068e7db-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 08 12:00:17 2021 Received: (at 45379) by debbugs.gnu.org; 8 Jan 2021 17:00:18 +0000 Received: from localhost ([127.0.0.1]:50527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxv7Z-0004Z2-L0 for submit@debbugs.gnu.org; Fri, 08 Jan 2021 12:00:17 -0500 Received: from mail-pg1-f176.google.com ([209.85.215.176]:45761) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxv7X-0004Yo-CO for 45379@debbugs.gnu.org; Fri, 08 Jan 2021 12:00:16 -0500 Received: by mail-pg1-f176.google.com with SMTP id v19so7970872pgj.12 for <45379@debbugs.gnu.org>; Fri, 08 Jan 2021 09:00:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=EieibBCQyu6GTUFsu72HCQpSOY0TEREitKkQ44TdZeE=; b=P2ljqf7Jd/F+sjqRuobb5wAC6HOvn+SfgaIhpybaXuVwacaOaCmCVCS8OzWFzPFSJ5 vx6lnRILl/5K2Ec5nktwSpUgzv42iCTPJqjzehlLMnTQkbrlee3/brNoOumiR3HS4SDQ V3ccu+jV1shKQhsvoToKzuecjZQLBkH0H6I4stbDRLSMQ3Wk3543wxd5CrVduVE18ZQV YSON0UYubet0ci3R0nJWK2+ppbST1LmLrhonv09v3GVLLVczG3YoET/APTOnEEsWQgJ7 LPh6u8b5UoTPKAzwE8XMT4uefhO9tRoXtuaTfnMyTAR89O+7g4yECq27k3IZ4uaW+d0Z z9Wg== X-Gm-Message-State: AOAM532UPwx7eZw6LwfF05nOYe2BHWF9xRVRr5cV/RBM40lvw5/Hz13R A0jgKKV7yGYWyhunVMAdkWbzebNbhqjyct3Jcc4= X-Google-Smtp-Source: ABdhPJwvqDoXwyiiB+hbTrQbnXEi8ALuHxi4JkicFi7zkfcro1nCFTI/cBbP+OgDO++nUJRv0q8ty0V9A5YkMHcIcp4= X-Received: by 2002:a63:6241:: with SMTP id w62mr7949430pgb.67.1610125209318; Fri, 08 Jan 2021 09:00:09 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Jan 2021 11:00:08 -0600 From: Stefan Kangas In-Reply-To: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> MIME-Version: 1.0 Date: Fri, 8 Jan 2021 11:00:08 -0600 Message-ID: Subject: Re: 28.0.50; Degraded Performance of describe-buffer-bindings To: Sheng Yang , Juri Linkov Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45379 Cc: martin rudalics , Eli Zaretskii , 45379@debbugs.gnu.org, Stefan Monnier , Stephen Berman X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) "Sheng Yang" writes: > Since I have received no reply after bug#45379 was reported (more than > 2 weeks), I guess it's better to contact you and cc every participants > of bug#5423. Thanks for the ping. I am working on a fix that I'm hoping to find the time to finish up soon, possibly already this weekend. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 08 12:00:34 2021 Received: (at control) by debbugs.gnu.org; 8 Jan 2021 17:00:34 +0000 Received: from localhost ([127.0.0.1]:50530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxv7p-0004ZY-VX for submit@debbugs.gnu.org; Fri, 08 Jan 2021 12:00:34 -0500 Received: from mail-pj1-f52.google.com ([209.85.216.52]:50260) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxv7o-0004ZM-0Q for control@debbugs.gnu.org; Fri, 08 Jan 2021 12:00:32 -0500 Received: by mail-pj1-f52.google.com with SMTP id lj6so3958624pjb.0 for ; Fri, 08 Jan 2021 09:00:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=jgHl6maxjsMAHe1oSGGcbyzxeyCCrWkWOht/EXFaEPY=; b=Mq3VXazQKNmNVxTUwyhf+BnEMjH83T27RRycTF8x5090xwvwp1kG2bA4J4nBt16YJQ JxLSlqkbBbaWUdEbHbGCtYWPD2Z4tOkLLH5+zQungq42VwK1dlsNmiNoyR3x64mAX0f7 YinprHSBtkp95/aQ2FpTlotehC57kG1TcsNvYgFuE88cpt07lfZ3TVOTTMDU0Wqk48+C b0SFYUByzZOmx29GwMLXRp/z0pklevQzEV/3Nrh37TbMyuvXRrfvjx9rsJ7opuv9qMgy 8fffuNinzL9sb5dUCn9xpaVslKzcfBw86bRhpckwriMJkaVSyRpxkULKWT+TPzyPm9Tx lt5A== X-Gm-Message-State: AOAM530U4V6YJHbvwUa8yEguFSIXm/i3v11cVOIgllRFD1jbM6YmhJWN FERWOWo3PGUYnxE6Slcjqzz9natsRQg7x6PnkKEkRks9 X-Google-Smtp-Source: ABdhPJw1gQO3V53NWK1UYnmCBR3wSkGhbn80ukDdm5EZewxps/Abf1C6Ue4G0pCZk4OcbtNe730GmERdDd8gInRppdM= X-Received: by 2002:a17:902:9309:b029:db:c725:d19c with SMTP id bc9-20020a1709029309b02900dbc725d19cmr7949199plb.39.1610125226110; Fri, 08 Jan 2021 09:00:26 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Jan 2021 11:00:25 -0600 From: Stefan Kangas MIME-Version: 1.0 Date: Fri, 8 Jan 2021 11:00:25 -0600 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 45379 + confirmed thanks Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.216.52 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.216.52 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 2.0 BLANK_SUBJECT Subject is present but empty X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 45379 + confirmed thanks Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.216.52 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.216.52 listed in list.dnswl.org] 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 2.0 BLANK_SUBJECT Subject is present but empty tags 45379 + confirmed thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 08 12:08:24 2021 Received: (at 45379) by debbugs.gnu.org; 8 Jan 2021 17:08:24 +0000 Received: from localhost ([127.0.0.1]:50537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxvFP-0004lO-Qq for submit@debbugs.gnu.org; Fri, 08 Jan 2021 12:08:24 -0500 Received: from mail-pf1-f172.google.com ([209.85.210.172]:38015) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxvFN-0004lA-Ie for 45379@debbugs.gnu.org; Fri, 08 Jan 2021 12:08:22 -0500 Received: by mail-pf1-f172.google.com with SMTP id d2so6626735pfq.5 for <45379@debbugs.gnu.org>; Fri, 08 Jan 2021 09:08:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=75uGo1k/TCBNyFHivx/rpG9IQ+7vWAjSpWkQ3bLTtAg=; b=cvqmA+hoq1LWlO/gTLBTNu7jlJvRuyLc283bjj+hi7IwDQg3bRMRPp/0MAMOiA9s4/ E1BoGGD0LRZZxutTGgzlBBXQNowPMp2rI5XYvTqjK4vdcmtKNhOZk4BrmKZHFvVA1Hrp w1Dv/bcyU3Vyvjn4yz2Fv9+scZN/enWmbY28mFtc80Kw/l72f22l5HUNfNYeAZJZSDtG 645atVMdTi4bLTlZUYhe3LAO71k27z8ZAg6nN/YPaKOgHV3D23pj7hOSxcsCoCiJ3Ep2 RMuHXDDPwvYucvDmJbmopHeMcv2oA4Y3Z3Ie959cR5X+QDzP51j6DWInnBny/6Lfeid4 M+BA== X-Gm-Message-State: AOAM530jk/W+BwbmABbS8w5q0zKhdX/bq50rJPDZZRXlRSX7jVT6OjgE 38R2OsjPIb8CMCGRkKdo8linlams/M4bErq2EGw= X-Google-Smtp-Source: ABdhPJxOyOiF2X+upNkCoymcz7yCIi+1OWstVe5W1OfINp4v/VfBDxpSYlybzeV0CyItImvsewf3KcXVHj/5YmGHFBA= X-Received: by 2002:a63:6241:: with SMTP id w62mr7986921pgb.67.1610125695464; Fri, 08 Jan 2021 09:08:15 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Jan 2021 11:08:15 -0600 From: Stefan Kangas In-Reply-To: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> MIME-Version: 1.0 Date: Fri, 8 Jan 2021 11:08:14 -0600 Message-ID: Subject: Re: 28.0.50; Degraded Performance of describe-buffer-bindings To: Sheng Yang , Juri Linkov Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45379 Cc: martin rudalics , Eli Zaretskii , 45379@debbugs.gnu.org, Stefan Monnier , Stephen Berman X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) "Sheng Yang" writes: > Hi Juri, > > I recently came across a regression of performance in Emacs for > describe bindings, which I have reported as bug#45379. After > bisection, the offending seems to be a commit a649034336 you pushed in > November 2020, to fix bug#5423. [...] > > a649034336 * bad Don't show key ranges if shadowed by different commands BTW, the offending commit is not Juri's. It is mine: Author: Stefan Kangas Date: Fri Nov 13 15:28:29 2020 +0100 Don't show key ranges if shadowed by different commands Thanks for the bug report! From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 04 10:43:54 2021 Received: (at 45379) by debbugs.gnu.org; 4 Feb 2021 15:43:54 +0000 Received: from localhost ([127.0.0.1]:42022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7gnR-0005A2-3P for submit@debbugs.gnu.org; Thu, 04 Feb 2021 10:43:54 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:51517) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l7gnQ-00059q-CQ for 45379@debbugs.gnu.org; Thu, 04 Feb 2021 10:43:52 -0500 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 0F3695C00E4; Thu, 4 Feb 2021 10:43:47 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Thu, 04 Feb 2021 10:43:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=yi/bqAjXHtIKM5S1U2iWw/zvYtJwXOZ GyuTqYo7p/tU=; b=pC57n2w4AWiUYZfC8AwhZdTYXPnyo0GPJcjOU6Uewo0eT7B 1ZcqblIHPuxg970tctKVuxjavr+g4w6mNJOJXmm9LQ9fQ8rMvxze7nmRUCF5K6B2 fjCXfJRO3bxbYQoW6TxPx76594TlwKdnql7fvpJ3Oa34TrV21wPi99pBiG0GCYX4 OkgIFzmKEfAQ48OYvfDr3teQikEibLD9nbbpdpG9RGxLl0Dt0Prmex7S41epiMno 3/Ppjr2mTxFDZxMqomtBtVLy4ODaJHij8lmysyPywB9EIhCjkI2+1lCsf7ZMzXSk k7iz+A/4X6p+lO7wpr/GdxiuxV29Z6hHXyVeitQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yi/bqA jXHtIKM5S1U2iWw/zvYtJwXOZGyuTqYo7p/tU=; b=NZikOYBcg4FqpOeRVJJihC lCw1kCYbE3ex7f0c1J7Z/rLRaGVpyw0VuaBjIILwdyQyj3rMjLTfU1Owag8fGg5v l2xI6NFm07E5H0wc+eHc0BOaibW+I+HJxqL4locpLsRsnk2BB5LCIYF9H0ErfL+T 49OrF+j9L4fbfru/CR7o/fqlrFgFGBDWIHCv1L2Zgz9N/052hkVktiKSdhpbf9gB w9S6rTV17thKKxcyqJ6Hk5h416j+s9DX2b/pzkHgJW6JYQQiU42RwUHMnTL4pR4O QtmweqoUfZ+IZeIgb+jsGc7HEaDnSuZmFSBU3WUsNhl5MNHkWxJF+WEJioUZ6Ezg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrgeeggdejudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfufhhvghn ghcujggrnhhgfdcuoehsthihrghnghesfhgrshhtmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeehleeutdduffffgeffieelteetvdduieehhfevgfdviedvtddtieefieeg geevjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsthihrghnghesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 22ED6A0005D; Thu, 4 Feb 2021 10:43:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-93-gef6c4048e6-fm-20210128.002-gef6c4048 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> Date: Thu, 04 Feb 2021 09:43:25 -0600 From: "Sheng Yang" To: "Stefan Kangas" , "Juri Linkov" Subject: Re: 28.0.50; Degraded Performance of describe-buffer-bindings Content-Type: multipart/alternative; boundary=7d78b844a1a94631be88cf7a46bbc050 X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 45379 Cc: martin rudalics , Eli Zaretskii , 45379@debbugs.gnu.org, Stefan Monnier , Stephen Berman X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --7d78b844a1a94631be88cf7a46bbc050 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Any update on this bug?=20 On Fri, Jan 8, 2021, at 11:08, Stefan Kangas wrote: > "Sheng Yang" writes: >=20 > > Hi Juri, > > > > I recently came across a regression of performance in Emacs for > > describe bindings, which I have reported as bug#45379. After > > bisection, the offending seems to be a commit a649034336 you pushed = in > > November 2020, to fix bug#5423. [...] > > > > a649034336 * bad Don't show key ranges if shadowed by different comm= ands >=20 > BTW, the offending commit is not Juri's. It is mine: >=20 > Author: Stefan Kangas > Date: Fri Nov 13 15:28:29 2020 +0100 >=20 > Don't show key ranges if shadowed by different commands >=20 > Thanks for the bug report! >=20 Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD candidate Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --7d78b844a1a94631be88cf7a46bbc050 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Any update on t= his bug?

On Fri, Jan 8, 2021, at 11:08, St= efan Kangas wrote:
"Sheng Yang" <styang@f= astmail.com> writes:

> Hi Juri,
>
> I recently came across a regression= of performance in Emacs for
> describe bindings, which= I have reported as bug#45379. After
> bisection, the o= ffending seems to be a commit a649034336 you pushed in
>= ; November 2020, to fix bug#5423. [...]
>
> a649034336 * bad Don't show key ranges if shadowed by different co= mmands

BTW, the offending commit is not Jur= i's.  It is mine:

    A= uthor: Stefan Kangas <stefan@mar= xist.se>
    Date:   Fri N= ov 13 15:28:29 2020 +0100

   = ;     Don't show key ranges if shadowed by different= commands

Thanks for the bug report!


Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD candidate
=
Computer Science Department
University of Maryland, College Park
E-mail: styan= g@fastmail.com
E-mail (old but sti= ll used): yangsheng6810@gmail= .com


--7d78b844a1a94631be88cf7a46bbc050-- From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 05 23:44:42 2021 Received: (at 45379) by debbugs.gnu.org; 6 Mar 2021 04:44:42 +0000 Received: from localhost ([127.0.0.1]:35845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIOny-0006wJ-4X for submit@debbugs.gnu.org; Fri, 05 Mar 2021 23:44:42 -0500 Received: from mail-pj1-f52.google.com ([209.85.216.52]:38753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIOnw-0006w1-Dj for 45379@debbugs.gnu.org; Fri, 05 Mar 2021 23:44:41 -0500 Received: by mail-pj1-f52.google.com with SMTP id q2-20020a17090a2e02b02900bee668844dso217488pjd.3 for <45379@debbugs.gnu.org>; Fri, 05 Mar 2021 20:44:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=6FP6XxRP0mHp0CBuxWl+jBG64Jpms1lBfwaIScH4Gt4=; b=nEAXOOFM4WEoZoup9S1tZxrDIeXj7MnviRZPZPuaZkdVLnXziIEQx50P6W39LoaEou SuB9jTrbB+/UAvBZeJxGkJEIiOnNwhikjhomB1lakVETiRnKU2ZCdZdpKkHK4iOhhCz2 zYFfe4b8O1TYTUnb3O5OlT/2rVRp5ueiKfK5cg0NITzb+EcNYz6JJlkULi+FgruEgT8g zgcxmcuFgH5Z/90g0oGfWJmcjrGbiSCVH8R/S9XMGYXDI7Pn5nXPfnn50bPUEuUxU/Y0 XM0u8t0Ab6MdxO0LZQZPAfAZhQL1wx9oM8dZO945oFmyt9KcrATJ2hYrkL+udt4GQceC i1vg== X-Gm-Message-State: AOAM531JW1Li8GHPWqyI1djRSE9rA3uHcxoo4wjZ8LdR6blA/HSqJruj BFtpVo+CJ0KY+1QNDdm9PGuyEM82kbuTlGt7XuY= X-Google-Smtp-Source: ABdhPJzvNXMkdISDGxnm1n9XOrd6dQzE8/1pYZGu6Z/XgBa2MtO95Yg0SKoKMW4j8LSWidwWYmqa6+jfMTM+v035+YY= X-Received: by 2002:a17:902:b683:b029:e5:d0a4:c545 with SMTP id c3-20020a170902b683b02900e5d0a4c545mr11815249pls.41.1615005874648; Fri, 05 Mar 2021 20:44:34 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 5 Mar 2021 20:44:33 -0800 From: Stefan Kangas In-Reply-To: (Stefan Kangas's message of "Fri, 8 Jan 2021 11:08:14 -0600") References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Date: Fri, 5 Mar 2021 20:44:33 -0800 Message-ID: Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings To: Sheng Yang Content-Type: multipart/mixed; boundary="000000000000780e1805bcd6db14" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45379 Cc: Stephen Berman , Juri Linkov , martin rudalics , Stefan Monnier , Eli Zaretskii , 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --000000000000780e1805bcd6db14 Content-Type: text/plain; charset="UTF-8" tags 45379 + patch thanks Stefan Kangas writes: > "Sheng Yang" writes: > >> Hi Juri, >> >> I recently came across a regression of performance in Emacs for >> describe bindings, which I have reported as bug#45379. After >> bisection, the offending seems to be a commit a649034336 you pushed in >> November 2020, to fix bug#5423. [...] >> >> a649034336 * bad Don't show key ranges if shadowed by different commands > > BTW, the offending commit is not Juri's. It is mine: > > Author: Stefan Kangas > Date: Fri Nov 13 15:28:29 2020 +0100 > > Don't show key ranges if shadowed by different commands Please try the attached patch and see that it fixes this performance regression. It turns out that we were doing unnecessary looping due to the above mentioned commit. While working on this, I also found that we can get rid of an unnecessary call to char_table_ref_and_range, which should make this function run even faster. I'm also copying in Kenichi Handa, who was the last to touch this code. Handa-san, please let us know if you have any comments on this patch. Thanks in advance. --000000000000780e1805bcd6db14 Content-Type: text/x-diff; charset="US-ASCII"; name="0001-Fix-describe-buffer-bindings-performance-regression.patch" Content-Disposition: attachment; filename="0001-Fix-describe-buffer-bindings-performance-regression.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: d0363175bcc4f359_0.1 RnJvbSBmOTVjNzVmMTExMmMxYWFlMGJkMDZhNjc1M2I2MGNlOGE1OTFkNmUyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTdGVmYW4gS2FuZ2FzIDxzdGVmYW5AbWFyeGlzdC5zZT4KRGF0 ZTogU2F0LCA2IE1hciAyMDIxIDA1OjMyOjMyICswMTAwClN1YmplY3Q6IFtQQVRDSF0gRml4IGRl c2NyaWJlLWJ1ZmZlci1iaW5kaW5ncyBwZXJmb3JtYW5jZSByZWdyZXNzaW9uCgoqIHNyYy9rZXlt YXAuYyAoZGVzY3JpYmVfdmVjdG9yKTogSW1wcm92ZSBjaGFyLXRhYmxlIHBlcmZvcm1hbmNlIGJ5 CnJlbW92aW5nIGFuIHVubmVjZXNzYXJ5IGxvb3AuICAoQnVnIzQ1Mzc5KQooc3ltc19vZl9rZXlt YXApIDxRc2VsZl9pbnNlcnRfY29tbWFuZD46IE5ldyBERUZTWU0uCi0tLQogc3JjL2tleW1hcC5j IHwgNDcgKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDEg ZmlsZSBjaGFuZ2VkLCAxOSBpbnNlcnRpb25zKCspLCAyOCBkZWxldGlvbnMoLSkKCmRpZmYgLS1n aXQgYS9zcmMva2V5bWFwLmMgYi9zcmMva2V5bWFwLmMKaW5kZXggNzgyOTMxZmFkZi4uYzcwZGY5 OGE2ZSAxMDA2NDQKLS0tIGEvc3JjL2tleW1hcC5jCisrKyBiL3NyYy9rZXltYXAuYwpAQCAtMjky MCw3ICsyOTIwLDcgQEAgZGVzY3JpYmVfdmVjdG9yIChMaXNwX09iamVjdCB2ZWN0b3IsIExpc3Bf T2JqZWN0IHByZWZpeCwgTGlzcF9PYmplY3QgYXJncywKICAgTGlzcF9PYmplY3Qgc3VwcHJlc3Mg PSBRbmlsOwogICBib29sIGZpcnN0ID0gdHJ1ZTsKICAgLyogUmFuZ2Ugb2YgZWxlbWVudHMgdG8g YmUgaGFuZGxlZC4gICovCi0gIGludCBmcm9tLCB0bywgc3RvcDsKKyAgaW50IHRvLCBzdG9wOwog CiAgIGlmICgha2V5bWFwX3ApCiAgICAgewpAQCAtMjk0MCwzMiArMjk0MCwzMyBAQCBkZXNjcmli ZV92ZWN0b3IgKExpc3BfT2JqZWN0IHZlY3RvciwgTGlzcF9PYmplY3QgcHJlZml4LCBMaXNwX09i amVjdCBhcmdzLAogICBpZiAocGFydGlhbCkKICAgICBzdXBwcmVzcyA9IGludGVybiAoInN1cHBy ZXNzLWtleW1hcCIpOwogCi0gIGZyb20gPSAwOworICAvKiBJZiBWRUNUT1IgaXMgYSBjaGFyLXRh YmxlLCB3ZSBoYWQgYmV0dGVyIHB1dCBhIGJvdW5kYXJ5CisgICAgIGJldHdlZW4gbm9ybWFsIGNo YXJhY3RlcnMgKC0jeDNGRkY3RikgYW5kIDgtYml0IGNoYXJhY3RlcnMKKyAgICAgKCN4M0ZGRjgw LSkuICAqLwogICBpZiAoQ0hBUl9UQUJMRV9QICh2ZWN0b3IpKQogICAgIHN0b3AgPSBNQVhfNV9C WVRFX0NIQVIgKyAxLCB0byA9IE1BWF9DSEFSICsgMTsKICAgZWxzZQogICAgIHN0b3AgPSB0byA9 IEFTSVpFICh2ZWN0b3IpOwogCi0gIGZvciAoaW50IGkgPSBmcm9tOyA7IGkrKykKKyAgZm9yIChp bnQgaSA9IDA7IGkgPCB0bzsgaSsrKQogICAgIHsKICAgICAgIGJvb2wgdGhpc19zaGFkb3dlZCA9 IGZhbHNlOwogICAgICAgTGlzcF9PYmplY3Qgc2hhZG93ZWRfYnkgPSBRbmlsOwotICAgICAgaW50 IHJhbmdlX2JlZywgcmFuZ2VfZW5kOworICAgICAgaW50IHJhbmdlX2JlZzsKICAgICAgIExpc3Bf T2JqZWN0IHZhbCwgdGVtMjsKIAogICAgICAgbWF5YmVfcXVpdCAoKTsKIAotICAgICAgaWYgKGkg PT0gc3RvcCkKLQl7Ci0JICBpZiAoaSA9PSB0bykKLQkgICAgYnJlYWs7Ci0JICBzdG9wID0gdG87 Ci0JfQotCiAgICAgICBpbnQgc3RhcnRpbmdfaSA9IGk7CiAKICAgICAgIGlmIChDSEFSX1RBQkxF X1AgKHZlY3RvcikpCiAJeworCSAgLyogVGFrZSBjYXJlIG9mIHRoZSBib3VuZGFyeS4gICovCisJ ICBpZiAoaSA9PSBzdG9wKQorCSAgICBzdG9wID0gdG87CisKKwkgIC8qIEZpbmQgdGhlIGZpcnN0 IGVsZW1lbnQgYmV0d2VlbiBpIGFuZCBzdG9wIC0gMS4gIFB1dCBpdHMKKwkgICAgIGluZGV4IGlu IGkuICAqLwogCSAgcmFuZ2VfYmVnID0gaTsKIAkgIGkgPSBzdG9wIC0gMTsKIAkgIHZhbCA9IGNo YXJfdGFibGVfcmVmX2FuZF9yYW5nZSAodmVjdG9yLCByYW5nZV9iZWcsICZyYW5nZV9iZWcsICZp KTsKQEAgLTMwMjQsMjEgKzMwMjUsOCBAQCBkZXNjcmliZV92ZWN0b3IgKExpc3BfT2JqZWN0IHZl Y3RvciwgTGlzcF9PYmplY3QgcHJlZml4LCBMaXNwX09iamVjdCBhcmdzLAogICAgICAgaW5zZXJ0 MSAoRmtleV9kZXNjcmlwdGlvbiAoa2x1ZGdlLCBwcmVmaXgpKTsKIAogICAgICAgLyogRmluZCBh bGwgY29uc2VjdXRpdmUgY2hhcmFjdGVycyBvciByb3dzIHRoYXQgaGF2ZSB0aGUgc2FtZQotCSBk ZWZpbml0aW9uLiAgQnV0LCBpZiBWRUNUT1IgaXMgYSBjaGFyLXRhYmxlLCB3ZSBoYWQgYmV0dGVy Ci0JIHB1dCBhIGJvdW5kYXJ5IGJldHdlZW4gbm9ybWFsIGNoYXJhY3RlcnMgKC0jeDNGRkY3Rikg YW5kCi0JIDgtYml0IGNoYXJhY3RlcnMgKCN4M0ZGRjgwLSkuICAqLwotICAgICAgaWYgKENIQVJf VEFCTEVfUCAodmVjdG9yKSkKLQl7Ci0JICB3aGlsZSAoaSArIDEgPCBzdG9wCi0JCSAmJiAocmFu Z2VfYmVnID0gaSArIDEsIHJhbmdlX2VuZCA9IHN0b3AgLSAxLAotCQkgICB2YWwgPSBjaGFyX3Rh YmxlX3JlZl9hbmRfcmFuZ2UgKHZlY3RvciwgcmFuZ2VfYmVnLAotCQkJCQkJICAgJnJhbmdlX2Jl ZywgJnJhbmdlX2VuZCksCi0JCSAgIHRlbTIgPSBnZXRfa2V5ZWx0ICh2YWwsIDApLAotCQkgICAh TklMUCAodGVtMikpCi0JCSAmJiAhTklMUCAoRmVxdWFsICh0ZW0yLCBkZWZpbml0aW9uKSkpCi0J ICAgIGkgPSByYW5nZV9lbmQ7Ci0JfQotICAgICAgZWxzZQorCSBkZWZpbml0aW9uLiAgKi8KKyAg ICAgIGlmICghQ0hBUl9UQUJMRV9QICh2ZWN0b3IpKQogCXdoaWxlIChpICsgMSA8IHN0b3AKIAkg ICAgICAgJiYgKHRlbTIgPSBnZXRfa2V5ZWx0IChBUkVGICh2ZWN0b3IsIGkgKyAxKSwgMCksCiAJ CSAgICFOSUxQICh0ZW0yKSkKQEAgLTMwNDcsMTAgKzMwMzUsMTIgQEAgZGVzY3JpYmVfdmVjdG9y IChMaXNwX09iamVjdCB2ZWN0b3IsIExpc3BfT2JqZWN0IHByZWZpeCwgTGlzcF9PYmplY3QgYXJn cywKIAogICAgICAgLyogTWFrZSBzdXJlIGZvdW5kIGNvbnNlY3V0aXZlIGtleXMgYXJlIGVpdGhl ciBub3Qgc2hhZG93ZWQgb3IsCiAJIGlmIHRoZXkgYXJlLCB0aGF0IHRoZXkgYXJlIHNoYWRvd2Vk IGJ5IHRoZSBzYW1lIGNvbW1hbmQuICAqLwotICAgICAgaWYgKENIQVJfVEFCTEVfUCAodmVjdG9y KSAmJiBpICE9IHN0YXJ0aW5nX2kpCisgICAgICBpZiAoQ0hBUl9UQUJMRV9QICh2ZWN0b3IpICYm IGkgIT0gc3RhcnRpbmdfaQorCSAgLyogSWdub3JlIGBzZWxmLWluc2VydC1jb21tYW5kJyBmb3Ig cGVyZm9ybWFuY2UuICAqLworCSAgJiYgIUVRIChkZWZpbml0aW9uLCBRc2VsZl9pbnNlcnRfY29t bWFuZCkpCiAJewogCSAgTGlzcF9PYmplY3Qga2V5ID0gbWFrZV9uaWxfdmVjdG9yICgxKTsKLQkg IGZvciAoaW50IGogPSBzdGFydGluZ19pICsgMTsgaiA8PSBpOyBqKyspCisJICBmb3IgKGludCBq ID0gcmFuZ2VfYmVnICsgMTsgaiA8PSBpOyBqKyspCiAJICAgIHsKIAkgICAgICBBU0VUIChrZXks IDAsIG1ha2VfZml4bnVtIChqKSk7CiAJICAgICAgTGlzcF9PYmplY3QgdGVtID0gc2hhZG93X2xv b2t1cCAoc2hhZG93LCBrZXksIFF0LCAwKTsKQEAgLTMxMDksNiArMzA5OSw3IEBAIHN5bXNfb2Zf a2V5bWFwICh2b2lkKQogICBERUZTWU0gKFFkZXNjcmliZV9tYXBfdHJlZSwgImRlc2NyaWJlLW1h cC10cmVlIik7CiAKICAgREVGU1lNIChRa2V5bWFwX2Nhbm9uaWNhbGl6ZSwgImtleW1hcC1jYW5v bmljYWxpemUiKTsKKyAgREVGU1lNIChRc2VsZl9pbnNlcnRfY29tbWFuZCwgInNlbGYtaW5zZXJ0 LWNvbW1hbmQiKTsKIAogICAvKiBOb3cgd2UgYXJlIHJlYWR5IHRvIHNldCB1cCB0aGlzIHByb3Bl cnR5LCBzbyB3ZSBjYW4KICAgICAgY3JlYXRlIGNoYXIgdGFibGVzLiAgKi8KLS0gCjIuMzAuMQoK --000000000000780e1805bcd6db14-- From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 03:15:44 2021 Received: (at 45379) by debbugs.gnu.org; 6 Mar 2021 08:15:44 +0000 Received: from localhost ([127.0.0.1]:35961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIS67-0005do-PT for submit@debbugs.gnu.org; Sat, 06 Mar 2021 03:15:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIS65-0005da-JK for 45379@debbugs.gnu.org; Sat, 06 Mar 2021 03:15:38 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34947) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIS5z-00019C-CQ; Sat, 06 Mar 2021 03:15:31 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4618 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lIS5y-0004tb-BN; Sat, 06 Mar 2021 03:15:30 -0500 Date: Sat, 06 Mar 2021 10:15:16 +0200 Message-Id: <83v9a4wve3.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas , Kenichi Handa In-Reply-To: (message from Stefan Kangas on Fri, 5 Mar 2021 20:44:33 -0800) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45379 Cc: juri@linkov.net, styang@fastmail.com, stephen.berman@gmx.net, rudalics@gmx.at, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Stefan Kangas > Date: Fri, 5 Mar 2021 20:44:33 -0800 > Cc: Juri Linkov , martin rudalics , Eli Zaretskii , > 45379@debbugs.gnu.org, Stefan Monnier , > Stephen Berman > > It turns out that we were doing unnecessary looping due to the above > mentioned commit. While working on this, I also found that we can get > rid of an unnecessary call to char_table_ref_and_range, which should > make this function run even faster. I'm not sure I understand the reasons for each of the changes here. char-tables are a tricky data structure, so I'd like to make sure this change doesn't make our code subtly incorrect. So could you please walk us through the proposed changes, adding explanations for each part as you go? (And what do char-tables have to do with describing key bindings, btw?) > I'm also copying in Kenichi Handa, who was the last to touch this code. > Handa-san, please let us know if you have any comments on this patch. > Thanks in advance. AFAICT, you didn't CC Kenichi; I have now added him to the discussion. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 06 20:43:02 2021 Received: (at 45379) by debbugs.gnu.org; 7 Mar 2021 01:43:02 +0000 Received: from localhost ([127.0.0.1]:38649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIiRe-0002pR-90 for submit@debbugs.gnu.org; Sat, 06 Mar 2021 20:43:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIiRZ-0002pB-94 for 45379@debbugs.gnu.org; Sat, 06 Mar 2021 20:42:56 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49440) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIiRR-0005ot-Vn; Sat, 06 Mar 2021 20:42:46 -0500 Received: from fl1-60-236-248-230.iba.mesh.ad.jp ([60.236.248.230]:49514 helo=shatin) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lIiRQ-0000no-EE; Sat, 06 Mar 2021 20:42:45 -0500 Received: from handa by shatin with local (Exim 4.93) (envelope-from ) id 1lIiRL-0003E4-Aw; Sun, 07 Mar 2021 10:42:39 +0900 From: handa To: Eli Zaretskii Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings In-Reply-To: <83v9a4wve3.fsf@gnu.org> (message from Eli Zaretskii on Sat, 06 Mar 2021 10:15:16 +0200) Date: Sun, 07 Mar 2021 10:42:39 +0900 Message-ID: <874khnzqls.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45379 Cc: handa@gnu.org, styang@fastmail.com, stephen.berman@gmx.net, stefan@marxist.se, juri@linkov.net, rudalics@gmx.at, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) In article <83v9a4wve3.fsf@gnu.org>, Eli Zaretskii writes: > > From: Stefan Kangas > > Date: Fri, 5 Mar 2021 20:44:33 -0800 > > Cc: Juri Linkov , martin rudalics , Eli Zaretskii , > > 45379@debbugs.gnu.org, Stefan Monnier , > > Stephen Berman > > > > It turns out that we were doing unnecessary looping due to the above > > mentioned commit. Could you show me what is "the above mentioned commit"? > > While working on this, I also found that we can get > > rid of an unnecessary call to char_table_ref_and_range, which should > > make this function run even faster. Is the patch for the above improvement the one included in the file 0001-Fix-describe-buffer-bindings-performance-regression.patch? > > I'm also copying in Kenichi Handa, who was the last to touch this code. > > Handa-san, please let us know if you have any comments on this patch. > > Thanks in advance. > AFAICT, you didn't CC Kenichi; I have now added him to the discussion. It was more than 10 years ago that I last read keymap.c, and since then, the code has been changed a lot. It will take some time to understand the latest code. --- K. Handa handa@gnu.org From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 01:15:35 2021 Received: (at 45379) by debbugs.gnu.org; 7 Mar 2021 06:15:35 +0000 Received: from localhost ([127.0.0.1]:38793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lImhO-00019t-51 for submit@debbugs.gnu.org; Sun, 07 Mar 2021 01:15:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lImhM-00019h-Nf for 45379@debbugs.gnu.org; Sun, 07 Mar 2021 01:15:29 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53660) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lImhF-0005qW-97; Sun, 07 Mar 2021 01:15:21 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3268 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lImhE-00016v-Cx; Sun, 07 Mar 2021 01:15:20 -0500 Date: Sun, 07 Mar 2021 08:15:10 +0200 Message-Id: <83r1krtrpt.fsf@gnu.org> From: Eli Zaretskii To: handa In-Reply-To: <874khnzqls.fsf@gnu.org> (message from handa on Sun, 07 Mar 2021 10:42:39 +0900) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <874khnzqls.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45379 Cc: handa@gnu.org, styang@fastmail.com, stephen.berman@gmx.net, stefan@marxist.se, juri@linkov.net, rudalics@gmx.at, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: handa > Cc: stefan@marxist.se, styang@fastmail.com, juri@linkov.net, rudalics@gmx.at, > 45379@debbugs.gnu.org, monnier@iro.umontreal.ca, > stephen.berman@gmx.net, handa@gnu.org > Date: Sun, 07 Mar 2021 10:42:39 +0900 > > In article <83v9a4wve3.fsf@gnu.org>, Eli Zaretskii writes: > > > > From: Stefan Kangas > > > Date: Fri, 5 Mar 2021 20:44:33 -0800 > > > Cc: Juri Linkov , martin rudalics , Eli Zaretskii , > > > 45379@debbugs.gnu.org, Stefan Monnier , > > > Stephen Berman > > > > > > It turns out that we were doing unnecessary looping due to the above > > > mentioned commit. > > Could you show me what is "the above mentioned commit"? This one, I guess: > commit a6490343366f2b2331a91dcb693effb3a9dd78f5 > Author: Stefan Kangas > AuthorDate: Fri Nov 13 15:28:29 2020 +0100 > Commit: Stefan Kangas > CommitDate: Sun Nov 22 02:45:03 2020 +0100 > > Don't show key ranges if shadowed by different commands > > * src/keymap.c (describe_vector): Make sure found consecutive keys > are either not shadowed or, if they are, that they are shadowed by > the same command. (Bug#9293) > * test/src/keymap-tests.el > (help--describe-vector/bug-9293-one-shadowed-in-range): New test. > > > While working on this, I also found that we can get > > > rid of an unnecessary call to char_table_ref_and_range, which should > > > make this function run even faster. > > Is the patch for the above improvement the one included in the file > 0001-Fix-describe-buffer-bindings-performance-regression.patch? Yes, it is. > > > I'm also copying in Kenichi Handa, who was the last to touch this code. > > > Handa-san, please let us know if you have any comments on this patch. > > > Thanks in advance. > > > AFAICT, you didn't CC Kenichi; I have now added him to the discussion. > > It was more than 10 years ago that I last read keymap.c, and since then, > the code has been changed a lot. It will take some time to understand > the latest code. Thanks in advance. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 03:12:25 2021 Received: (at 45379) by debbugs.gnu.org; 7 Mar 2021 08:12:25 +0000 Received: from localhost ([127.0.0.1]:38854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIoWX-0004H4-7K for submit@debbugs.gnu.org; Sun, 07 Mar 2021 03:12:25 -0500 Received: from mail-pf1-f172.google.com ([209.85.210.172]:44084) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIoWW-0004Gr-9g for 45379@debbugs.gnu.org; Sun, 07 Mar 2021 03:12:24 -0500 Received: by mail-pf1-f172.google.com with SMTP id t29so5057013pfg.11 for <45379@debbugs.gnu.org>; Sun, 07 Mar 2021 00:12:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=bTYLzNNnDDJOSf2N3DR9GIASH7LOJra6HpjH7NkSPdo=; b=TUX1gH46EHqrR+4gq4MKNxiffol9oKrWHvaSYG81p6/wx6n0vuJvDUBMLS9s/OXGE9 HSQV7cd3hteJBJ666Ur0S+RcNr1XJZv0MNY7R/JvxyrrkKZpTKEZRAPl1D2usuBeenWM /DLoMxd1injlHlUTdDhMstRPoIf81W03NHJvJKRuh2v2VaCTBJIwiqL1ncw7yk2+V2py i+i4iCB53ZhflWOM1oNCVohY+mWFT76jKJVcIVZwWn/bnyXp3pHqTZ7t6qUgrjDgfrDm tNMjZwaiF2oCWH96JJzqoeY73cPMGqwMn8DXYrgfUoj1KSaPQXINxpB48JnL6qkEo2f6 iBCQ== X-Gm-Message-State: AOAM531J4OWPHOpoY7592ziP28i+1HBWrnjQnmRtlgFMr6SkfCL6hjXr 6qet71bh4xtIvhrlBTNtx22NHOEkhFC4EgK7TdU= X-Google-Smtp-Source: ABdhPJycdIlS2fOcRG5XTYBr7lIglfpjHk+RuU96IPRpBehRR4LI2Fe42Krm2GeZLWI25YEpa8rKPULrNdhaVp/H0jE= X-Received: by 2002:a63:6206:: with SMTP id w6mr13712545pgb.363.1615104738570; Sun, 07 Mar 2021 00:12:18 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 7 Mar 2021 03:12:17 -0500 From: Stefan Kangas In-Reply-To: <83v9a4wve3.fsf@gnu.org> References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> <83v9a4wve3.fsf@gnu.org> MIME-Version: 1.0 Date: Sun, 7 Mar 2021 03:12:17 -0500 Message-ID: Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings To: Eli Zaretskii , Kenichi Handa Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45379 Cc: juri@linkov.net, styang@fastmail.com, stephen.berman@gmx.net, rudalics@gmx.at, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Eli Zaretskii writes: >> It turns out that we were doing unnecessary looping due to the above >> mentioned commit. While working on this, I also found that we can get >> rid of an unnecessary call to char_table_ref_and_range, which should >> make this function run even faster. > > I'm not sure I understand the reasons for each of the changes here. > char-tables are a tricky data structure, so I'd like to make sure this > change doesn't make our code subtly incorrect. Thanks. I have been struggling to come up with good unit tests, so any ideas about that would also be very welcome. > So could you please walk us through the proposed changes, adding > explanations for each part as you go? Yes. Please allow for at least a couple of days to write this up. > (And what do char-tables have to do with describing key bindings, > btw?) Full keymaps are char-tables, while sparse keymaps are just lists. The call stack looks like this: Fdescribe_buffer_bindings [keymap.c] -> describe-map-tree [help.el] -> describe-map -> Fhelp__describe_vector [keymap.c] -> describe_vector From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 07 03:38:47 2021 Received: (at 45379) by debbugs.gnu.org; 7 Mar 2021 08:38:47 +0000 Received: from localhost ([127.0.0.1]:38875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIovx-0004uR-MT for submit@debbugs.gnu.org; Sun, 07 Mar 2021 03:38:47 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lIovu-0004uD-3p for 45379@debbugs.gnu.org; Sun, 07 Mar 2021 03:38:40 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54542) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIovl-0004bh-Uh; Sun, 07 Mar 2021 03:38:29 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4135 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lIovl-0003sW-Cm; Sun, 07 Mar 2021 03:38:29 -0500 Date: Sun, 07 Mar 2021 10:38:19 +0200 Message-Id: <83ft17tl38.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Sun, 7 Mar 2021 03:12:17 -0500) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> <83v9a4wve3.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45379 Cc: styang@fastmail.com, rudalics@gmx.at, stephen.berman@gmx.net, juri@linkov.net, handa@gnu.org, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Stefan Kangas > Date: Sun, 7 Mar 2021 03:12:17 -0500 > Cc: styang@fastmail.com, juri@linkov.net, rudalics@gmx.at, > 45379@debbugs.gnu.org, monnier@iro.umontreal.ca, stephen.berman@gmx.net > > > So could you please walk us through the proposed changes, adding > > explanations for each part as you go? > > Yes. Please allow for at least a couple of days to write this up. Sure. There's no rush, please take your time. > > (And what do char-tables have to do with describing key bindings, > > btw?) > > Full keymaps are char-tables, while sparse keymaps are just lists. > > The call stack looks like this: > > Fdescribe_buffer_bindings [keymap.c] > -> describe-map-tree [help.el] > -> describe-map > -> Fhelp__describe_vector [keymap.c] > -> describe_vector Got it, thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 02:58:19 2021 Received: (at control) by debbugs.gnu.org; 30 Mar 2021 06:58:19 +0000 Received: from localhost ([127.0.0.1]:50220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lR8KQ-00086y-TM for submit@debbugs.gnu.org; Tue, 30 Mar 2021 02:58:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lR8KP-00086i-Be; Tue, 30 Mar 2021 02:58:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60813) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lR8KJ-0002so-SH; Tue, 30 Mar 2021 02:58:11 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4948 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lR8KI-0002k0-J5; Tue, 30 Mar 2021 02:58:11 -0400 Date: Tue, 30 Mar 2021 09:58:21 +0300 Message-Id: <83a6qlku0i.fsf@gnu.org> From: Eli Zaretskii To: Mark Oteiza In-Reply-To: (message from Mark Oteiza on Tue, 30 Mar 2021 02:13:09 -0400) Subject: Re: bug#47494: 28.0.50; describe-mode is now slow References: X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control Cc: 47494@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) merge 47494 45379 thanks > Date: Tue, 30 Mar 2021 02:13:09 -0400 > From: Mark Oteiza > > >From -Q: C-h m > > Takes about a second here. Looking at the profiler, it's split between > some new function and the garbage collector: > > 118 52% - # > 118 52% - mapatoms > 118 52% + help-fns--list-local-commands > 92 41% Automatic GC > > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=98e3ee27472 This is a known bug#45379, we are trying to solve it. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 30 03:01:24 2021 Received: (at 45379) by debbugs.gnu.org; 30 Mar 2021 07:01:24 +0000 Received: from localhost ([127.0.0.1]:50231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lR8NL-0000wq-89 for submit@debbugs.gnu.org; Tue, 30 Mar 2021 03:01:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36880) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lR8NI-0000qf-Ph for 45379@debbugs.gnu.org; Tue, 30 Mar 2021 03:01:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60840) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lR8NB-0004jw-VS; Tue, 30 Mar 2021 03:01:09 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1160 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lR8NA-0008Ob-24; Tue, 30 Mar 2021 03:01:08 -0400 Date: Tue, 30 Mar 2021 10:01:19 +0300 Message-Id: <838s65ktvk.fsf@gnu.org> From: Eli Zaretskii To: Kenichi Handa In-Reply-To: <83r1krtrpt.fsf@gnu.org> (message from Eli Zaretskii on Sun, 07 Mar 2021 08:15:10 +0200) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <874khnzqls.fsf@gnu.org> <83r1krtrpt.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45379 Cc: stephen.berman@gmx.net, stefan@marxist.se, juri@linkov.net, handa@gnu.org, styang@fastmail.com, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ping! Kenichi, could you please help us with this issue? > Date: Sun, 07 Mar 2021 08:15:10 +0200 > From: Eli Zaretskii > Cc: stephen.berman@gmx.net, 45379@debbugs.gnu.org, stefan@marxist.se, > juri@linkov.net, handa@gnu.org, monnier@iro.umontreal.ca, styang@fastmail.com > > > From: handa > > Cc: stefan@marxist.se, styang@fastmail.com, juri@linkov.net, rudalics@gmx.at, > > 45379@debbugs.gnu.org, monnier@iro.umontreal.ca, > > stephen.berman@gmx.net, handa@gnu.org > > Date: Sun, 07 Mar 2021 10:42:39 +0900 > > > > In article <83v9a4wve3.fsf@gnu.org>, Eli Zaretskii writes: > > > > > > From: Stefan Kangas > > > > Date: Fri, 5 Mar 2021 20:44:33 -0800 > > > > Cc: Juri Linkov , martin rudalics , Eli Zaretskii , > > > > 45379@debbugs.gnu.org, Stefan Monnier , > > > > Stephen Berman > > > > > > > > It turns out that we were doing unnecessary looping due to the above > > > > mentioned commit. > > > > Could you show me what is "the above mentioned commit"? > > This one, I guess: > > > commit a6490343366f2b2331a91dcb693effb3a9dd78f5 > > Author: Stefan Kangas > > AuthorDate: Fri Nov 13 15:28:29 2020 +0100 > > Commit: Stefan Kangas > > CommitDate: Sun Nov 22 02:45:03 2020 +0100 > > > > Don't show key ranges if shadowed by different commands > > > > * src/keymap.c (describe_vector): Make sure found consecutive keys > > are either not shadowed or, if they are, that they are shadowed by > > the same command. (Bug#9293) > > * test/src/keymap-tests.el > > (help--describe-vector/bug-9293-one-shadowed-in-range): New test. > > > > > While working on this, I also found that we can get > > > > rid of an unnecessary call to char_table_ref_and_range, which should > > > > make this function run even faster. > > > > Is the patch for the above improvement the one included in the file > > 0001-Fix-describe-buffer-bindings-performance-regression.patch? > > Yes, it is. > > > > > I'm also copying in Kenichi Handa, who was the last to touch this code. > > > > Handa-san, please let us know if you have any comments on this patch. > > > > Thanks in advance. > > > > > AFAICT, you didn't CC Kenichi; I have now added him to the discussion. > > > > It was more than 10 years ago that I last read keymap.c, and since then, > > the code has been changed a lot. It will take some time to understand > > the latest code. > > Thanks in advance. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 01 11:06:58 2021 Received: (at 45379) by debbugs.gnu.org; 1 Apr 2021 15:06:58 +0000 Received: from localhost ([127.0.0.1]:58273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRyuP-0002i5-Qi for submit@debbugs.gnu.org; Thu, 01 Apr 2021 11:06:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lRyuO-0002hr-FN for 45379@debbugs.gnu.org; Thu, 01 Apr 2021 11:06:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56249) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRyuH-00053j-DX; Thu, 01 Apr 2021 11:06:49 -0400 Received: from fl1-60-236-248-230.iba.mesh.ad.jp ([60.236.248.230]:52042 helo=shatin) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRyuF-0001N4-2A; Thu, 01 Apr 2021 11:06:48 -0400 Received: from handa by shatin with local (Exim 4.93) (envelope-from ) id 1lRyu9-0008Lx-1D; Fri, 02 Apr 2021 00:06:41 +0900 From: handa To: Eli Zaretskii Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings In-Reply-To: <838s65ktvk.fsf@gnu.org> (message from Eli Zaretskii on Tue, 30 Mar 2021 10:01:19 +0300) Date: Fri, 02 Apr 2021 00:06:40 +0900 Message-ID: <87v996rqm7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45379 Cc: stephen.berman@gmx.net, stefan@marxist.se, juri@linkov.net, styang@fastmail.com, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) In article <838s65ktvk.fsf@gnu.org>, Eli Zaretskii writes: > > > Is the patch for the above improvement the one included in the file > > > 0001-Fix-describe-buffer-bindings-performance-regression.patch? > > > > Yes, it is. It seems that the main intention of that patch is to avoid unnecessary call of char_table_ref_and_range introduced by the commit below: > > Don't show key ranges if shadowed by different commands > > > > * src/keymap.c (describe_vector): Make sure found consecutive keys > > are either not shadowed or, if they are, that they are shadowed by > > the same command. (Bug#9293) In describe_vector, if VECTOR is a char-table, char_table_ref_and_range is already called at the fairly beginning of the main loop. So, we do not have to call it again, and thus, I think the patch is doing the correct thing. But, I don't know whether the following part in the patch is correct or not. + /* Ignore `self-insert-command' for performance. */ + && !EQ (definition, Qself_insert_command)) --- K. Handa handa@gnu.org From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 02 10:56:18 2021 Received: (at control) by debbugs.gnu.org; 2 Apr 2021 14:56:18 +0000 Received: from localhost ([127.0.0.1]:60875 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lSLDe-00013W-4c for submit@debbugs.gnu.org; Fri, 02 Apr 2021 10:56:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49608) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lSLDc-00013G-RN; Fri, 02 Apr 2021 10:56:17 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33098) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lSLDW-0001d0-3O; Fri, 02 Apr 2021 10:56:11 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3721 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lSLDV-0007WG-E1; Fri, 02 Apr 2021 10:56:09 -0400 Date: Fri, 02 Apr 2021 17:55:55 +0300 Message-Id: <835z14g2h0.fsf@gnu.org> From: Eli Zaretskii To: Naveed Chehrazi In-Reply-To: (message from Naveed Chehrazi on Fri, 2 Apr 2021 09:45:36 -0500) Subject: Re: bug#47565: 28.0.50; help-fns--list-local-commands slows Emacs References: X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control Cc: 47565@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) merge 47565 45379 thanks > From: Naveed Chehrazi > Date: Fri, 2 Apr 2021 09:45:36 -0500 > > Please see the issue I opened on Spacemacs github page: > > https://github.com/syl20bnr/spacemacs/issues/14585 > > Briefly, Spacemacs is extremely slow when I use describe commands (C-h > m, C-h v, ...). I ran an experiment with two identical machines. The > only difference were the version of Emacs: 28.0.50 and 27.1.91. > > The machine with version 27.1.91 is of order of magnitude faster. The > output of the profiler is included below: This is a known bug#45379, we are trying to solve it. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 13 23:06:59 2021 Received: (at 45379) by debbugs.gnu.org; 14 Apr 2021 03:06:59 +0000 Received: from localhost ([127.0.0.1]:33067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWVrn-00063v-3d for submit@debbugs.gnu.org; Tue, 13 Apr 2021 23:06:59 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:34255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lWVrk-00063i-Qw for 45379@debbugs.gnu.org; Tue, 13 Apr 2021 23:06:58 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A1E0C5C1682; Tue, 13 Apr 2021 23:06:51 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Tue, 13 Apr 2021 23:06:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=v9ekw1jIbIHZFe4/ow+3336xJ4tQ0RT +povgVt0wXfQ=; b=Zu6yKEH8JDLEKef+uqW6+wNYOGeB+R420bMujuqV0pXSclM KWmPUAuQFrfJlaYtPxgjm8yfO+3w4ZR/q9U+EBt96zevh/TPEeBNpAYReG0okeXu /ND4jRqbn1cOxO4Qn7RzRoeUDG9Y2PROHggt4T+w5lHbqHzJYaF2yH3wieBO/tx2 3O9M+RvpCvz8Yqn6TqsSYYz/Y2Ribo5N9WgBQajYWGP/Ls3ZkyX6DGgXaS3ym1i5 ukC5RIEaf5s55pusU37PMqKZ73ZiJYtfq4Z5OLaYpfcRz9r5FQKBLR+tsSF/+OaA Z6LT324WOCIMgwECiLyxWFBxyorqnlzEg1E5/fw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=v9ekw1 jIbIHZFe4/ow+3336xJ4tQ0RT+povgVt0wXfQ=; b=CYMhNS7AHlVcS1TqSKJ6rA UXOeugC5m4eij/IReH8Y9YMdL6nln/dBrPHTqZj01AE4BK8ArmpOhLcDPn8H0e1A TGJwIk80GI41N7xV+EiiqLDQ8A/8YXX8h/BlG9ikS5LZ5BQG1M+IZDNka6L1zID6 83vOhX0AcgVezVePZLQWXGwth0/Leu4K6tdTuugqi+YPNGLitLeV40nz3djI/y+5 6WaWreZElPB2VcrCfsghvpDW63tuBI2s4BUNbP9AYwA5BIP8tQrMkxmINN2wdlC3 ujLCXQCOioAfg36iO8ino/RJL95iAP3RvYwl1k8rOH4AeTZiPj0DO5FX4cqb9Shg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeltddgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfuhhgv nhhgucgjrghnghdfuceoshhthigrnhhgsehfrghsthhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepheeluedtudffffegffeileettedvudeihefhvefgvdeivddttdeifeei geegveejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epshhthigrnhhgsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 59713A00490; Tue, 13 Apr 2021 23:06:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: In-Reply-To: <87v996rqm7.fsf@gnu.org> References: <87v996rqm7.fsf@gnu.org> Date: Tue, 13 Apr 2021 22:06:29 -0500 From: "Sheng Yang" To: handa , "Eli Zaretskii" Subject: =?UTF-8?Q?Re:_bug#45379:_28.0.50; _Degraded_Performance_of_describe-buffe?= =?UTF-8?Q?r-bindings?= Content-Type: multipart/alternative; boundary=b6b26e12b04b420c95ab9adc87599d43 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 45379 Cc: 45379@debbugs.gnu.org, Stephen Berman , Stefan Kangas , Stefan Monnier , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --b6b26e12b04b420c95ab9adc87599d43 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Any update on this? Having been using the patch for a few weeks now, see= ms fine for me. On Thu, Apr 1, 2021, at 10:06, handa wrote: > In article <838s65ktvk.fsf@gnu.org >,= Eli Zaretskii > writes: >=20 > > > > Is the patch for the above improvement the one included in the f= ile > > > > 0001-Fix-describe-buffer-bindings-performance-regression.patch? > > >=20 > > > Yes, it is. >=20 > It seems that the main intention of that patch is to avoid unnecessary= > call of char_table_ref_and_range introduced by the commit below: >=20 > > > Don't show key ranges if shadowed by different commands > > >=20 > > > * src/keymap.c (describe_vector): Make sure found consecutive = keys > > > are either not shadowed or, if they are, that they are shadowe= d by > > > the same command. (Bug#9293) >=20 > In describe_vector, if VECTOR is a char-table, char_table_ref_and_rang= e > is already called at the fairly beginning of the main loop. So, we do= > not have to call it again, and thus, I think the patch is doing the > correct thing. >=20 > But, I don't know whether the following part in the patch is correct o= r > not. >=20 > + /* Ignore `self-insert-command' for performance. */ > + && !EQ (definition, Qself_insert_command)) >=20 > --- > K. Handa > handa@gnu.org >=20 Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --b6b26e12b04b420c95ab9adc87599d43 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Any update on t= his? Having been using the patch for a few weeks now, seems fine for me.=

On Thu, Apr 1, 2021, at 10:06, handa wrote= :
In articl= e <838s65ktvk.fsf@gnu.org= >, Eli Zaretskii <eliz@gnu.o= rg> writes:

> > > Is the pa= tch for the above improvement the one included in the file
> > > 0001-Fix-describe-buffer-bindings-performance-regression= .patch?
> > 
> > Yes, it is= .

It seems that the main intention of that = patch is to avoid unnecessary
call of char_table_ref_and_r= ange introduced by the commit below:

> &= gt;     Don't show key ranges if shadowed by differe= nt commands
> > 
> > &= nbsp;   * src/keymap.c (describe_vector): Make sure found cons= ecutive keys
> >     are either = not shadowed or, if they are, that they are shadowed by
&g= t; >     the same command.  (Bug#9293)

In describe_vector, if VECTOR is a char-table, c= har_table_ref_and_range
is already called at the fairly be= ginning of the main loop.  So, we do
not have to call= it again, and thus, I think the patch is doing the
correc= t thing.

But, I don't know whether the foll= owing part in the patch is correct or
not.
<= br>
+   /* Ignore `self-insert-command' for performance.&= nbsp; */
+   && !EQ (definition, Qself_insert= _command))

---
K. Handa
<= div>

Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD
Computer Science Department
University of Maryland, College Park
E-mail: styang@fastmail.com=
E-mail (old but still used): yangsheng6810@gmail.com


--b6b26e12b04b420c95ab9adc87599d43-- From debbugs-submit-bounces@debbugs.gnu.org Tue May 04 19:31:20 2021 Received: (at 45379) by debbugs.gnu.org; 4 May 2021 23:31:20 +0000 Received: from localhost ([127.0.0.1]:56060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1le4Vc-0001RS-1L for submit@debbugs.gnu.org; Tue, 04 May 2021 19:31:20 -0400 Received: from mail-pf1-f174.google.com ([209.85.210.174]:36801) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1le4VZ-0001R7-57 for 45379@debbugs.gnu.org; Tue, 04 May 2021 19:31:18 -0400 Received: by mail-pf1-f174.google.com with SMTP id p4so658395pfo.3 for <45379@debbugs.gnu.org>; Tue, 04 May 2021 16:31:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=h/t//vg7uIczPpI8PkJC3nw6QCgF33tjnEHC9bu9gOM=; b=kuXwBVQVS/5GjWCeVo/1NdUMQeBfTh1RM7RX69h+IQKe+O+sLlIpXBxy6vRV0zJEEP n/1Si2y0ddDRjptKn77LQYtSA9dNOL5/sqITMVQ/CKhHVmEHt/LqLjJ4lSLsYsnMnU/P jZP0HqeMaW88Ha2rdqKraTomZC0najyPL0ya5qk2g02Lq31zhDnMeq/R+e9/PALtv0bz Vrqp4qswsT/+qN/s4Uxcgc+Xmr5RtvyCmNaInGQm45I+9e+5mGevPwttJ4Ol6oYSYAoN jekBaaJ6uk2FQTeVF2X/P+wc/YzKwDzXERVtUJey/OI0HZV28tl50//BuNkqOU2Tuwef H7Tg== X-Gm-Message-State: AOAM532aG248wKszG5nWr20KieLOYzfsRnyqj/vimy3lwJGiHhifmiHl PEgR6oUAK4deSMOfxtbFe+1JUoAcc5JDpa8otHY= X-Google-Smtp-Source: ABdhPJzwQlPLgcn45x3BE5WVF5DP9ujA1Gyi50h90fUyurUiMEis0fMcu0FITJ5STEguFqR5C5zL1BzhRtq1on38Bbc= X-Received: by 2002:a17:90a:b38a:: with SMTP id e10mr30938628pjr.175.1620171071301; Tue, 04 May 2021 16:31:11 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 4 May 2021 18:31:10 -0500 From: Stefan Kangas In-Reply-To: References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> MIME-Version: 1.0 Date: Tue, 4 May 2021 18:31:10 -0500 Message-ID: Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings To: Sheng Yang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45379 Cc: Stephen Berman , Kenichi Handa , Juri Linkov , martin rudalics , Stefan Monnier , Eli Zaretskii , 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) I finally had time/energy to look into this again! Sorry for taking more time than expected. handa writes: > In article <838s65ktvk.fsf@gnu.org>, Eli Zaretskii writes: > >> > > Is the patch for the above improvement the one included in the file >> > > 0001-Fix-describe-buffer-bindings-performance-regression.patch? >> > >> > Yes, it is. > > It seems that the main intention of that patch is to avoid unnecessary > call of char_table_ref_and_range introduced by the commit below: > >> > Don't show key ranges if shadowed by different commands >> > >> > * src/keymap.c (describe_vector): Make sure found consecutive keys >> > are either not shadowed or, if they are, that they are shadowed by >> > the same command. (Bug#9293) > > In describe_vector, if VECTOR is a char-table, char_table_ref_and_range > is already called at the fairly beginning of the main loop. So, we do > not have to call it again, and thus, I think the patch is doing the > correct thing. Yes, this is all correct. > But, I don't know whether the following part in the patch is correct or > not. > > + /* Ignore `self-insert-command' for performance. */ > + && !EQ (definition, Qself_insert_command)) (This is explained below.) Eli Zaretskii writes: > I'm not sure I understand the reasons for each of the changes here. > char-tables are a tricky data structure, so I'd like to make sure this > change doesn't make our code subtly incorrect. > > So could you please walk us through the proposed changes, adding > explanations for each part as you go? This code is a bit complicated, so please bare with me if I am going into too much detail. BTW, note that I have also carried out a lot of testing to see that my change does the same thing as before, only faster (unfortunately it has been harder to come up with useful automated tests beyond the ones we already have). First, it might help to think of this as consisting of two parts: 1. A cleanup of the boundary condition check. It is simply to make this code a bit more clear and easier to follow. 2. The actual bug fix for the performance bug. I put a divider in between these two parts to make things hopefully a bit more clear. Stefan Kangas writes: > From f95c75f1112c1aae0bd06a6753b60ce8a591d6e2 Mon Sep 17 00:00:00 2001 > From: Stefan Kangas > Date: Sat, 6 Mar 2021 05:32:32 +0100 > Subject: [PATCH] Fix describe-buffer-bindings performance regression > > * src/keymap.c (describe_vector): Improve char-table performance by > removing an unnecessary loop. (Bug#45379) > (syms_of_keymap) : New DEFSYM. > --- > src/keymap.c | 47 +++++++++++++++++++---------------------------- > 1 file changed, 19 insertions(+), 28 deletions(-) > > diff --git a/src/keymap.c b/src/keymap.c > index 782931fadf..c70df98a6e 100644 > --- a/src/keymap.c > +++ b/src/keymap.c > @@ -2920,7 +2920,7 @@ describe_vector (Lisp_Object vector, Lisp_Object pr= efix, Lisp_Object args, > Lisp_Object suppress =3D Qnil; > bool first =3D true; > /* Range of elements to be handled. */ > - int from, to, stop; > + int to, stop; > > if (!keymap_p) > { > @@ -2940,32 +2940,33 @@ describe_vector (Lisp_Object vector, Lisp_Object = prefix, Lisp_Object args, > if (partial) > suppress =3D intern ("suppress-keymap"); > > - from =3D 0; The "from" variable is initialized to 0 below and is redundant. So it is replaced with the constant 0, which I think makes the intention of this code more clear. IOW, this is just a cleanup. > + /* If VECTOR is a char-table, we had better put a boundary > + between normal characters (-#x3FFF7F) and 8-bit characters > + (#x3FFF80-). */ > if (CHAR_TABLE_P (vector)) > stop =3D MAX_5_BYTE_CHAR + 1, to =3D MAX_CHAR + 1; > else > stop =3D to =3D ASIZE (vector); The above puts a "boundary" that we need to handle below by stopping (skipping to the next range) when we reach "stop". We must end the loop altogether only when we reach "to". Note that for char tables stop !=3D to, otherwise stop =3D=3D to > > - for (int i =3D from; ; i++) > + for (int i =3D 0; i < to; i++) > { Here we stop when we reach "to", which is what we intend. The "from" mentioned above is also here replaced with constant 0. > bool this_shadowed =3D false; > Lisp_Object shadowed_by =3D Qnil; > - int range_beg, range_end; > + int range_beg; [range_end is now unused and so removed.] > Lisp_Object val, tem2; > > maybe_quit (); > > - if (i =3D=3D stop) > - { > - if (i =3D=3D to) > - break; This is a bit complicated to follow, so I have cleaned it up. What happens here is that we exit the loop if "i =3D=3D to". The rest is to handle the above "boundary". We have two cases: 1. If this is not a char table: i =3D=3D stop implies that i =3D=3D to (The loop will always end here.) 2. If this is a char table: i =3D=3D stop does not imply that i =3D=3D to a) The loop will end if i =3D=3D stop =E2=88=A7 i =3D=3D to (This can never be the case the first time we reach this, see above. We must first have reached the 2b) immediately below in a previous iteration.) > - stop =3D to; > - } > - b) Otherwise, if "i =3D=3D stop =E2=88=A7 i !=3D to", we set "stop =3D to= " (Again, only when this has happened can we reach 2a.) But this is all removed, so the 2b) action is moved here: > int starting_i =3D i; > > if (CHAR_TABLE_P (vector)) > { > + /* Take care of the boundary. */ > + if (i =3D=3D stop) > + stop =3D to; IOW, here "i !=3D to", but "i =3D=3D stop" so we set "stop =3D to". Just a= s before. Thus, the boundary condition is handled. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=93 End part 1, performance bug fix = follows: > + /* Find the first element between i and stop - 1. Put its > + index in i. */ > range_beg =3D i; > i =3D stop - 1; > val =3D char_table_ref_and_range (vector, range_beg, &range_beg, &i); ^^^^^^^^^^^^^^^^^^^^^^^^ First call to "char_table_ref_and_range". This puts the correct values in the "range_beg" variables and "i", where "range_beg" is the start of the range and "i" is the last item in the range that has the same value. This is followed by: > } > else > val =3D AREF (vector, i); > Lisp_Object definition =3D get_keyelt (val, 0); > > if (NILP (definition)) continue; IOW, we skip it if it is not defined. This is important to see why we can remove the next part. > @@ -3024,21 +3025,8 @@ describe_vector (Lisp_Object vector, Lisp_Object p= refix, Lisp_Object args, > insert1 (Fkey_description (kludge, prefix)); > > /* Find all consecutive characters or rows that have the same > - definition. But, if VECTOR is a char-table, we had better > - put a boundary between normal characters (-#x3FFF7F) and > - 8-bit characters (#x3FFF80-). */ > - if (CHAR_TABLE_P (vector)) > - { > - while (i + 1 < stop > - && (range_beg =3D i + 1, range_end =3D stop - 1, > - val =3D char_table_ref_and_range (vector, range_beg, > - &range_beg, &range_end), ^^^^^^^^^^^^^^^^^^^^^^^^ This second call simply tries to call up a *second* range within the same iteration. This is to "put a boundary" (commit bed6185fecbb), but it is crucial to note this is _already handled_ above. This is therefore superfluous, as we can see from what happens next: > - tem2 =3D get_keyelt (val, 0), > - !NILP (tem2)) > - && !NILP (Fequal (tem2, definition))) > - i =3D range_end; This is all just to continue advancing down the char table until we find something. Again, note that above we already do exactly the same thing, so doing it here as well is superfluous. I.e. compare these statements to the lines above, specifically: Lisp_Object definition =3D get_keyelt (val, 0); if (NILP (definition)) continue; Pay particular attention to the variables i, range_beg, and range_end. > - } > - else > + definition. */ > + if (!CHAR_TABLE_P (vector)) > while (i + 1 < stop > && (tem2 =3D get_keyelt (AREF (vector, i + 1), 0), > !NILP (tem2)) (Note that there is no change if this is not a char-table.) > @@ -3047,10 +3035,12 @@ describe_vector (Lisp_Object vector, Lisp_Object = prefix, Lisp_Object args, > > /* Make sure found consecutive keys are either not shadowed or, > if they are, that they are shadowed by the same command. */ > - if (CHAR_TABLE_P (vector) && i !=3D starting_i) > + if (CHAR_TABLE_P (vector) && i !=3D starting_i > + /* Ignore `self-insert-command' for performance. */ > + && !EQ (definition, Qself_insert_command)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ To see if the shadowing is the same for an entire range, we need to run shadow_lookup() for *once for each character* in that range to see if they are shadowed. This is expensive. One observation is that we often have *very long* ranges of characters where the value is "self-insert-command", as in: (lookup-key global-map "=E6=96=87") This is because a char-table will cover the range of all valid character codes. [Note again that we use a char-table only if the keymap is defined with `make-keymap' (as opposed to `make-sparse-keymap', which is just a list)] Let's just assume that it is unlikely that there is any shadowing going on for all of these self-inserting keys. If there is shadowing going on, we are probably not looking at a keymap where we have the default value is set to self-insert-command. So we basically say here: let's just not care about `self-insert-command' and skip the check. Yes, we will in theory not get a perfect result, as there will be some cases where we miss the shadowing. OTOH, we are sure to have something that is not very slow. (And in any case, I don't know of any examples where this will fail, and if they exist we will in any case already be doing better than Emacs 27, as this entire check is new in Emacs 28.) > { > Lisp_Object key =3D make_nil_vector (1); > - for (int j =3D starting_i + 1; j <=3D i; j++) > + for (int j =3D range_beg + 1; j <=3D i; j++) ^^^^^^^^^^ ("range_beg" is the start of the actual range here, previously it was starting_i due to the second call to char_table_ref_and_range.) > { > ASET (key, 0, make_fixnum (j)); > Lisp_Object tem =3D shadow_lookup (shadow, key, Qt, 0); > @@ -3109,6 +3099,7 @@ syms_of_keymap (void) > DEFSYM (Qdescribe_map_tree, "describe-map-tree"); > > DEFSYM (Qkeymap_canonicalize, "keymap-canonicalize"); > + DEFSYM (Qself_insert_command, "self-insert-command"); > > /* Now we are ready to set up this property, so we can > create char tables. */ > -- > 2.30.1 Phew! From debbugs-submit-bounces@debbugs.gnu.org Thu May 06 06:12:01 2021 Received: (at 45379) by debbugs.gnu.org; 6 May 2021 10:12:02 +0000 Received: from localhost ([127.0.0.1]:37196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1leaz8-0003xs-1W for submit@debbugs.gnu.org; Thu, 06 May 2021 06:12:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1leaz6-0003xm-Eh for 45379@debbugs.gnu.org; Thu, 06 May 2021 06:11:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55178) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1leayz-0008Vl-Tl; Thu, 06 May 2021 06:11:49 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2731 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from ) id 1leayy-0008Qr-8Y; Thu, 06 May 2021 06:11:49 -0400 Date: Thu, 06 May 2021 13:11:37 +0300 Message-Id: <83k0ocdvdy.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Tue, 4 May 2021 18:31:10 -0500) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45379 Cc: juri@linkov.net, styang@fastmail.com, handa@gnu.org, stephen.berman@gmx.net, rudalics@gmx.at, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Tue, 4 May 2021 18:31:10 -0500 > Cc: Juri Linkov , martin rudalics , Eli Zaretskii , > 45379@debbugs.gnu.org, Stefan Monnier , > Stephen Berman , Kenichi Handa > > I finally had time/energy to look into this again! Sorry for taking > more time than expected. Thanks for your time and efforts. I will review this as soon as I have enough time to do so. From debbugs-submit-bounces@debbugs.gnu.org Thu May 13 06:10:45 2021 Received: (at 45379) by debbugs.gnu.org; 13 May 2021 10:10:45 +0000 Received: from localhost ([127.0.0.1]:41389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lh8Ij-0001Md-A8 for submit@debbugs.gnu.org; Thu, 13 May 2021 06:10:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lh8If-0001MM-GB for 45379@debbugs.gnu.org; Thu, 13 May 2021 06:10:40 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36426) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lh8IY-0006Rn-AX; Thu, 13 May 2021 06:10:30 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2783 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lh8IX-0005yd-SV; Thu, 13 May 2021 06:10:30 -0400 Date: Thu, 13 May 2021 13:10:38 +0300 Message-Id: <83o8df0wrl.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Tue, 4 May 2021 18:31:10 -0500) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45379 Cc: juri@linkov.net, styang@fastmail.com, handa@gnu.org, stephen.berman@gmx.net, rudalics@gmx.at, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Tue, 4 May 2021 18:31:10 -0500 > Cc: Juri Linkov , martin rudalics , Eli Zaretskii , > 45379@debbugs.gnu.org, Stefan Monnier , > Stephen Berman , Kenichi Handa > > I finally had time/energy to look into this again! Sorry for taking > more time than expected. Thanks. And I have finally found enough free time to review this. A couple of comments below, and then I'm okay with installing these changes. > > But, I don't know whether the following part in the patch is correct or > > not. > > > > + /* Ignore `self-insert-command' for performance. */ > > + && !EQ (definition, Qself_insert_command)) > > (This is explained below.) And I have a comment for that explanation. > > Lisp_Object val, tem2; > > > > maybe_quit (); > > > > - if (i == stop) > > - { > > - if (i == to) > > - break; > > This is a bit complicated to follow, so I have cleaned it up. I don't see the modified code regarding this to/stop issue as more clear than the original one. In both cases there's a special test which then sets stop = to. I needed to read the new code several times to convince myself we perform the same amount of run-time tests inside the loop. So I'd prefer to leave this nit alone, as it was in the original code. If you find that somewhat unclear, how about adding a comment there explaining whatever it was unclear to you when you first read that? > > @@ -3047,10 +3035,12 @@ describe_vector (Lisp_Object vector, Lisp_Object prefix, Lisp_Object args, > > > > /* Make sure found consecutive keys are either not shadowed or, > > if they are, that they are shadowed by the same command. */ > > - if (CHAR_TABLE_P (vector) && i != starting_i) > > + if (CHAR_TABLE_P (vector) && i != starting_i > > + /* Ignore `self-insert-command' for performance. */ > > + && !EQ (definition, Qself_insert_command)) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > To see if the shadowing is the same for an entire range, we need to run > shadow_lookup() for *once for each character* in that range to see if > they are shadowed. This is expensive. > > One observation is that we often have *very long* ranges of characters > where the value is "self-insert-command", as in: > > (lookup-key global-map "文") > > This is because a char-table will cover the range of all valid character > codes. [Note again that we use a char-table only if the keymap is > defined with `make-keymap' (as opposed to `make-sparse-keymap', which is > just a list)] > > Let's just assume that it is unlikely that there is any shadowing going > on for all of these self-inserting keys. If there is shadowing going > on, we are probably not looking at a keymap where we have the default > value is set to self-insert-command. > > So we basically say here: let's just not care about > `self-insert-command' and skip the check. Yes, we will in theory not > get a perfect result, as there will be some cases where we miss the > shadowing. OTOH, we are sure to have something that is not very slow. > (And in any case, I don't know of any examples where this will fail, and > if they exist we will in any case already be doing better than Emacs 27, > as this entire check is new in Emacs 28.) To tell the truth, I'm a bit worried by this "assumption", and so was Handa-san. This part of the change looks to me like simply ignoring a legitimate situation which we previously supported, and now will not, for the sole reason that the test is slow. Who can tell us what this could cause in some code somewhere in the community? "Don't know any examples where it will fail" is not very assuring, IMO. Is this part of the change what speeds up describe-buffer-bindings? Or is this just part of the speedup? In the latter case, how much faster will describe-buffer-bindings become without this "optimization"? And in the former case, I'd prefer to have this "optimization" controllable by some variable, which we could then use in the future as a "fire escape" if someone comes up with a use case where the code you want to remove is indeed needed. Alternatively, how about making the "Don't show key ranges if shadowed by different commands" feature, which triggered this regression, optional, by default off? Then people who want it could be warned that it might slow down describe-buffer-bindings, and will have to decide whether they care enough about the speed to have the feature turned on. In any case, at least some of this explanation should be in comments to the code, no matter whether we leave it alone or bypass it conditionally. If we introduce a variable to control this, some of this should be in the doc string of that variable. Thanks again for working on this, and sorry it took me so long to get to review it. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 03 13:15:38 2021 Received: (at control) by debbugs.gnu.org; 3 Jun 2021 17:15:38 +0000 Received: from localhost ([127.0.0.1]:44619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1loqwU-0003vJ-H8 for submit@debbugs.gnu.org; Thu, 03 Jun 2021 13:15:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1loqwS-0003v2-7a; Thu, 03 Jun 2021 13:15:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60110) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loqwM-0006fo-KB; Thu, 03 Jun 2021 13:15:30 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4969 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loqwM-00086M-6g; Thu, 03 Jun 2021 13:15:30 -0400 Date: Thu, 03 Jun 2021 20:15:19 +0300 Message-Id: <83czt2x42g.fsf@gnu.org> From: Eli Zaretskii To: Naofumi Yasufuku In-Reply-To: (message from Naofumi Yasufuku on Fri, 4 Jun 2021 00:06:55 +0900) Subject: Re: bug#48812: 28.0.50; describe-bindings stucks and gets high CPU load References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control Cc: 48812@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) merge 48812 45379 thanks > From: Naofumi Yasufuku > Date: Fri, 4 Jun 2021 00:06:55 +0900 > > This describe-bindings stuck is caused by millions of shadow_lookup() calls > in src/keymap.c describe_vector(). This is a duplicate of bug#45379. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 26 17:51:51 2021 Received: (at 45379) by debbugs.gnu.org; 26 Jun 2021 21:51:51 +0000 Received: from localhost ([127.0.0.1]:48742 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxGDP-0005ah-0m for submit@debbugs.gnu.org; Sat, 26 Jun 2021 17:51:51 -0400 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:59909) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxGDL-0005aS-Rh for 45379@debbugs.gnu.org; Sat, 26 Jun 2021 17:51:49 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B359E32000EB; Sat, 26 Jun 2021 17:51:41 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sat, 26 Jun 2021 17:51:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=bjhDvYm/wPfI7PeEfBRxsrz3dgFAeAR B+20fK1X5Jfk=; b=DUbJ+7jrDrH6vsvOx8nT7axwGWosC4Uv16Ie3GaDjfqi+GB IhQ7BxVUZpSlA8dIQZd9R4H6/G1gVVBc9YHX+WrF/xuvNP6KDE7Qvr9ld0L5eFLv b1UhAar9TQGTpinYlt1mL9iKh2RGB3ywoNRj8HSpTeUkvH0xEn+ffx3FQ8TtJTMV kGcSdmYjZUSJ5BnlSQucjAPB43D/NhH27rTCFOFAQi495eFOy3eXBLSvr3nWqpbo 3KrK+deRLLsoDFk6X5YRjLEG8vPnzNNU5+DppmgB3OySF2BhIFdT5KNlYfzwDxAX tXtFBvsylL7F8nV4irxCl1wft9eZ4cyjKb2spVQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=bjhDvY m/wPfI7PeEfBRxsrz3dgFAeARB+20fK1X5Jfk=; b=qdxStitwaNyekDU7/e7i5J tm5ynT2Pkvfyrw0dCmbdjEz/Cpb4CiJHIccLKNQQxvja+xA8B+FqZJ0cDoMYd3fT IzcsCYURRaTzftnz3ekIDhukb0grfs1RkblGCe5Z+eNFTWwe2tC6iSHOoq8fANZN twTjCtXv0I0BZ2FVVeS44OZwgSZBg3AtEdeVl1AscN6h7RJICQk0t1lqauyEw87z hJ1RdhXRJZOq9y8klp2a8KIl+ez1cwf6GDXQ7hvStuhO46jVxFRr5s9dZsN52PI/ 2qC6ogXsBk2OydaleiDvQPilX6s52AzXoGWupLelYdYfTxMyAsJSFPNfC124IQwg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeehudcutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfufhhvghnghcu jggrnhhgfdcuoehsthihrghnghesfhgrshhtmhgrihhlrdgtohhmqeenucggtffrrghtth gvrhhnpeehleeutdduffffgeffieelteetvdduieehhfevgfdviedvtddtieefieeggeev jeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsth ihrghnghesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 83C33A002CB; Sat, 26 Jun 2021 17:51:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578 Mime-Version: 1.0 Message-Id: In-Reply-To: <83o8df0wrl.fsf@gnu.org> References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> <83o8df0wrl.fsf@gnu.org> Date: Sat, 26 Jun 2021 16:51:19 -0500 From: "Sheng Yang" To: "Eli Zaretskii" , "Stefan Kangas" Subject: =?UTF-8?Q?Re:_bug#45379:_28.0.50; _Degraded_Performance_of_describe-buffe?= =?UTF-8?Q?r-bindings?= Content-Type: multipart/alternative; boundary=faffe4babe284626a9a920b562c33f0d X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 45379 Cc: Stephen Berman , martin rudalics , Juri Linkov , handa , Stefan Monnier , 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --faffe4babe284626a9a920b562c33f0d Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable A month has passed, any update on this? I see someone also reported this= issue on the mailing list today. Sheng Yang(=E6=9D=A8=E5=9C=A3), PhD Computer Science Department University of Maryland, College Park E-mail: styang@fastmail.com E-mail (old but still used): yangsheng6810@gmail.com --faffe4babe284626a9a920b562c33f0d Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
A month ha= s passed, any update on this? I see someone also reported this issue on = the mailing list today.


Sheng Yang(=E6=9D=A8=E5=9C=A3), P= hD
Computer Science Department
University of Maryland, College Park
E-mail: styang@fastmail.com
E-mail (old b= ut still used): yangsheng6810= @gmail.com

--faffe4babe284626a9a920b562c33f0d-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 27 01:56:28 2021 Received: (at 45379) by debbugs.gnu.org; 27 Jun 2021 05:56:28 +0000 Received: from localhost ([127.0.0.1]:48883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxNmK-0001MO-7Y for submit@debbugs.gnu.org; Sun, 27 Jun 2021 01:56:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxNmI-0001M9-I9 for 45379@debbugs.gnu.org; Sun, 27 Jun 2021 01:56:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56658) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lxNmA-0006eq-MY; Sun, 27 Jun 2021 01:56:14 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3228 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lxNmA-0004MO-1a; Sun, 27 Jun 2021 01:56:14 -0400 Date: Sun, 27 Jun 2021 08:56:09 +0300 Message-Id: <83y2avq29y.fsf@gnu.org> From: Eli Zaretskii To: "Sheng Yang" In-Reply-To: (styang@fastmail.com) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> <83o8df0wrl.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45379 Cc: stephen.berman@gmx.net, handa@gnu.org, stefan@marxist.se, juri@linkov.net, rudalics@gmx.at, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 26 Jun 2021 16:51:19 -0500 > From: "Sheng Yang" > Cc: "Juri Linkov" , "martin rudalics" , > 45379@debbugs.gnu.org, "Stefan Monnier" , > "Stephen Berman" , handa > > A month has passed, any update on this? I see someone also reported this issue on the mailing list today. Not yet, sorry. I guess Stefan has other things on his plate. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 07 14:53:26 2021 Received: (at 45379) by debbugs.gnu.org; 7 Sep 2021 18:53:26 +0000 Received: from localhost ([127.0.0.1]:57735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mNgDg-0004of-Ip for submit@debbugs.gnu.org; Tue, 07 Sep 2021 14:53:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43520) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mNgDd-0004nx-Ra for 45379@debbugs.gnu.org; Tue, 07 Sep 2021 14:53:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33026) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mNgDX-0007c5-O9; Tue, 07 Sep 2021 14:53:11 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4540 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNgDX-0000FY-9H; Tue, 07 Sep 2021 14:53:11 -0400 Date: Tue, 07 Sep 2021 21:53:16 +0300 Message-Id: <83r1e0nroj.fsf@gnu.org> From: Eli Zaretskii To: stefan@marxist.se In-Reply-To: <83o8df0wrl.fsf@gnu.org> (message from Eli Zaretskii on Thu, 13 May 2021 13:10:38 +0300) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> <83o8df0wrl.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45379 Cc: stephen.berman@gmx.net, rudalics@gmx.at, 45379@debbugs.gnu.org, juri@linkov.net, handa@gnu.org, monnier@iro.umontreal.ca, styang@fastmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ping! Stefan, can we please resolve this issue? I think we cannot release Emacs 28 without fixing this regression. TIA > Date: Thu, 13 May 2021 13:10:38 +0300 > From: Eli Zaretskii > Cc: juri@linkov.net, styang@fastmail.com, handa@gnu.org, stephen.berman@gmx.net, > rudalics@gmx.at, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org > > > From: Stefan Kangas > > Date: Tue, 4 May 2021 18:31:10 -0500 > > Cc: Juri Linkov , martin rudalics , Eli Zaretskii , > > 45379@debbugs.gnu.org, Stefan Monnier , > > Stephen Berman , Kenichi Handa > > > > I finally had time/energy to look into this again! Sorry for taking > > more time than expected. > > Thanks. And I have finally found enough free time to review this. A > couple of comments below, and then I'm okay with installing these > changes. > > > > But, I don't know whether the following part in the patch is correct or > > > not. > > > > > > + /* Ignore `self-insert-command' for performance. */ > > > + && !EQ (definition, Qself_insert_command)) > > > > (This is explained below.) > > And I have a comment for that explanation. > > > > Lisp_Object val, tem2; > > > > > > maybe_quit (); > > > > > > - if (i == stop) > > > - { > > > - if (i == to) > > > - break; > > > > This is a bit complicated to follow, so I have cleaned it up. > > I don't see the modified code regarding this to/stop issue as more > clear than the original one. In both cases there's a special test > which then sets stop = to. I needed to read the new code several > times to convince myself we perform the same amount of run-time tests > inside the loop. So I'd prefer to leave this nit alone, as it was in > the original code. If you find that somewhat unclear, how about > adding a comment there explaining whatever it was unclear to you when > you first read that? > > > > @@ -3047,10 +3035,12 @@ describe_vector (Lisp_Object vector, Lisp_Object prefix, Lisp_Object args, > > > > > > /* Make sure found consecutive keys are either not shadowed or, > > > if they are, that they are shadowed by the same command. */ > > > - if (CHAR_TABLE_P (vector) && i != starting_i) > > > + if (CHAR_TABLE_P (vector) && i != starting_i > > > + /* Ignore `self-insert-command' for performance. */ > > > + && !EQ (definition, Qself_insert_command)) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > To see if the shadowing is the same for an entire range, we need to run > > shadow_lookup() for *once for each character* in that range to see if > > they are shadowed. This is expensive. > > > > One observation is that we often have *very long* ranges of characters > > where the value is "self-insert-command", as in: > > > > (lookup-key global-map "文") > > > > This is because a char-table will cover the range of all valid character > > codes. [Note again that we use a char-table only if the keymap is > > defined with `make-keymap' (as opposed to `make-sparse-keymap', which is > > just a list)] > > > > Let's just assume that it is unlikely that there is any shadowing going > > on for all of these self-inserting keys. If there is shadowing going > > on, we are probably not looking at a keymap where we have the default > > value is set to self-insert-command. > > > > So we basically say here: let's just not care about > > `self-insert-command' and skip the check. Yes, we will in theory not > > get a perfect result, as there will be some cases where we miss the > > shadowing. OTOH, we are sure to have something that is not very slow. > > (And in any case, I don't know of any examples where this will fail, and > > if they exist we will in any case already be doing better than Emacs 27, > > as this entire check is new in Emacs 28.) > > To tell the truth, I'm a bit worried by this "assumption", and so was > Handa-san. This part of the change looks to me like simply ignoring a > legitimate situation which we previously supported, and now will not, > for the sole reason that the test is slow. Who can tell us what this > could cause in some code somewhere in the community? "Don't know any > examples where it will fail" is not very assuring, IMO. > > Is this part of the change what speeds up describe-buffer-bindings? > Or is this just part of the speedup? In the latter case, how much > faster will describe-buffer-bindings become without this > "optimization"? And in the former case, I'd prefer to have this > "optimization" controllable by some variable, which we could then use > in the future as a "fire escape" if someone comes up with a use case > where the code you want to remove is indeed needed. > > Alternatively, how about making the "Don't show key ranges if shadowed > by different commands" feature, which triggered this regression, > optional, by default off? Then people who want it could be warned > that it might slow down describe-buffer-bindings, and will have to > decide whether they care enough about the speed to have the feature > turned on. > > In any case, at least some of this explanation should be in comments > to the code, no matter whether we leave it alone or bypass it > conditionally. If we introduce a variable to control this, some of > this should be in the doc string of that variable. > > Thanks again for working on this, and sorry it took me so long to get > to review it. > > > > From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 18 06:38:27 2021 Received: (at 45379) by debbugs.gnu.org; 18 Sep 2021 10:38:27 +0000 Received: from localhost ([127.0.0.1]:33641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRXjm-0007Q9-TK for submit@debbugs.gnu.org; Sat, 18 Sep 2021 06:38:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:32820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRXji-0007Pr-5T for 45379@debbugs.gnu.org; Sat, 18 Sep 2021 06:38:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49208) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRXjZ-0001OB-JC; Sat, 18 Sep 2021 06:38:15 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4929 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRXjY-0007S0-Sl; Sat, 18 Sep 2021 06:38:13 -0400 Date: Sat, 18 Sep 2021 13:37:57 +0300 Message-Id: <8335q26uey.fsf@gnu.org> From: Eli Zaretskii To: stefan@marxist.se In-Reply-To: <83r1e0nroj.fsf@gnu.org> (message from Eli Zaretskii on Tue, 07 Sep 2021 21:53:16 +0300) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> <83o8df0wrl.fsf@gnu.org> <83r1e0nroj.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45379 Cc: stephen.berman@gmx.net, juri@linkov.net, handa@gnu.org, styang@fastmail.com, monnier@iro.umontreal.ca, Lars Ingebrigtsen , 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 07 Sep 2021 21:53:16 +0300 > From: Eli Zaretskii > Cc: stephen.berman@gmx.net, handa@gnu.org, juri@linkov.net, styang@fastmail.com, > monnier@iro.umontreal.ca, 45379@debbugs.gnu.org > > Ping! Stefan, can we please resolve this issue? I think we cannot > release Emacs 28 without fixing this regression. Since we are close to cutting the emacs-28 release branch, and this bug didn't see any loving care for a long time, I went ahead and fixed this performance degradation myself, based on patches by Stefan Kangas and their discussions in this bug report. The feature whereby we check whether shadowing of consecutive keys is by the same command, which AFAIU is what caused the regression, is now optional, by default off. There's a new variable, 'describe-bindings-check-shadowing-in-ranges', which can be used to turn it on, and an optional value of that variable, 'ignore-self-insert', which provides some partial testing of shadowing in these cases by trading accuracy for performance. I also left alone parts of the code where Stefan proposed changes of stylistic character. And I have a question about this whole "shadowing detection" feature. If I repeat the recipe of bug#9293, which started all this, i.e. emacs -Q C-x C-f some-tarball-file.tar.gz RET M-x view-mode RET C-h m then the *Help* buffer shows this at its start: key binding --- ------- 0 .. 9 digit-argument e tar-extract (currently shadowed by ‘View-exit’) f tar-extract C-d tar-flag-deleted RET tar-extract (this binding is currently shadowed) C-n tar-next-line C-p tar-previous-line SPC tar-next-line (this binding is currently shadowed) C tar-copy (this binding is currently shadowed) Note how the shadowing of 'e' is described with the command that shadows it, but the shadowing of RET, SPC, and 'C' isn't. Why is that? Is that a separate bug? (This display was there even before my changes, so I don't think the latest changes were the culprit; but for some reason bug#9293 discussed only a small part of the *Help* display and never looked beyond that.) Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 18 08:34:19 2021 Received: (at 45379) by debbugs.gnu.org; 18 Sep 2021 12:34:19 +0000 Received: from localhost ([127.0.0.1]:33788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRZXv-0008M8-C9 for submit@debbugs.gnu.org; Sat, 18 Sep 2021 08:34:19 -0400 Received: from mail-pf1-f180.google.com ([209.85.210.180]:36370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRZXr-0008Lq-Vg for 45379@debbugs.gnu.org; Sat, 18 Sep 2021 08:34:18 -0400 Received: by mail-pf1-f180.google.com with SMTP id m26so11819253pff.3 for <45379@debbugs.gnu.org>; Sat, 18 Sep 2021 05:34:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=fyGe9LD6yW99rCD9SeuIznNjW+CaR6erJnZlspGpxEM=; b=oaxU26UnNvQ0rhaSxAHhdkiBTq+8Pn54eUSx4tdQJHEzwGgHxzKQZ4sphYDS80AMJ2 hWN0qP5p1A/NSjpAoy3vX+WjRJ4kLJA01JCjA+iwOSfOK/dN9bwLtk7WqlKYTLlBpRCH VCCWYdVuF1TP/OboX2DlCRIAMo2UdvbhBhSt1j7s69Udt0CqQ3sU+S4/pqxkpsjebY7n DCWTiPr7LGjkErcpEr1FJkKglupIDhsULOJCHqCnVeVCY1SIGfSebhMFq8fa+CEoXn2/ cSxL7bpSt+Jrzshbc5PK4Xf01uI6+AK4T0f594/I5ivALYp9SnOOdhzfW0Wf4uqwdP/A g3Bg== X-Gm-Message-State: AOAM532DN6g3Lf6nS4GOapk1FHjljJYNVwYVF6LYUcyk1FxPLwqMxm4t fEgvm8YrZbdcVqdCTRwC9i9T6FTNfVQHrCMEYiQ= X-Google-Smtp-Source: ABdhPJyYSN0gCP0DlEgjwTtCSXDP4ibz6N5EkMYN6uH6eth4uPlNNcwJ7yEmmxYdk0D/4K176iWJYO9PFUPdVkJYUX8= X-Received: by 2002:aa7:9e90:0:b0:43f:2abb:a504 with SMTP id p16-20020aa79e90000000b0043f2abba504mr16000620pfq.35.1631968450146; Sat, 18 Sep 2021 05:34:10 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 18 Sep 2021 05:34:08 -0700 From: Stefan Kangas In-Reply-To: <8335q26uey.fsf@gnu.org> References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> <83o8df0wrl.fsf@gnu.org> <83r1e0nroj.fsf@gnu.org> <8335q26uey.fsf@gnu.org> MIME-Version: 1.0 Date: Sat, 18 Sep 2021 05:34:08 -0700 Message-ID: Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45379 Cc: stephen.berman@gmx.net, juri@linkov.net, handa@gnu.org, styang@fastmail.com, monnier@iro.umontreal.ca, Lars Ingebrigtsen , 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Eli Zaretskii writes: >> Date: Tue, 07 Sep 2021 21:53:16 +0300 >> From: Eli Zaretskii >> Cc: stephen.berman@gmx.net, handa@gnu.org, juri@linkov.net, styang@fastm= ail.com, >> monnier@iro.umontreal.ca, 45379@debbugs.gnu.org >> >> Ping! Stefan, can we please resolve this issue? I think we cannot >> release Emacs 28 without fixing this regression. > > Since we are close to cutting the emacs-28 release branch, and this > bug didn't see any loving care for a long time, I went ahead and fixed > this performance degradation myself, based on patches by Stefan Kangas > and their discussions in this bug report. Thanks, I appreciate the help. [I had intended to get to it this weekend based on your recent ping; for me this stuff (as opposed to ELisp shenanigans) requires a decent chunk of time to sit down and properly focus.] > The feature whereby we check whether shadowing of consecutive keys is > by the same command, which AFAIU is what caused the regression, is now > optional, by default off. There's a new variable, > 'describe-bindings-check-shadowing-in-ranges', which can be used to > turn it on, and an optional value of that variable, > 'ignore-self-insert', which provides some partial testing of shadowing > in these cases by trading accuracy for performance. OK. The bug doesn't directly affect me, but now people who are affected can enable the bug fix. > And I have a question about this whole "shadowing detection" feature. > If I repeat the recipe of bug#9293, which started all this, i.e. > > emacs -Q > C-x C-f some-tarball-file.tar.gz RET > M-x view-mode RET > C-h m > > then the *Help* buffer shows this at its start: > > key binding > --- ------- > > 0 .. 9 digit-argument > e tar-extract (currently shadowed by =E2=80=98View-exit=E2=80=99) > f tar-extract > > C-d tar-flag-deleted > RET tar-extract > (this binding is currently shadowed) > C-n tar-next-line > C-p tar-previous-line > SPC tar-next-line > (this binding is currently shadowed) > C tar-copy > (this binding is currently shadowed) > > Note how the shadowing of 'e' is described with the command that > shadows it, but the shadowing of RET, SPC, and 'C' isn't. Why is > that? Is that a separate bug? It is a separate bug, I think. The "currently shadowed part" is new in commit fb9326b45c76, but it was never fixed for the second case. Which of the two messages is shown has to do with whether or not this is a regular keymap or a sparse keymap. They were always handled slightly differently, but now we have the changed message for one of them that makes this visible. > for some reason bug#9293 discussed only a small part of the *Help* > display and never looked beyond that. I overlooked the case you mention, indeed. From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 18 09:25:12 2021 Received: (at 45379) by debbugs.gnu.org; 18 Sep 2021 13:25:12 +0000 Received: from localhost ([127.0.0.1]:33866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRaL5-0001CX-2J for submit@debbugs.gnu.org; Sat, 18 Sep 2021 09:25:12 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRaL1-0001C0-3F for 45379@debbugs.gnu.org; Sat, 18 Sep 2021 09:25:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52338) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRaKu-0002Mc-Gr; Sat, 18 Sep 2021 09:24:56 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3436 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRaKu-0001yl-2d; Sat, 18 Sep 2021 09:24:56 -0400 Date: Sat, 18 Sep 2021 16:24:41 +0300 Message-Id: <83sfy2584m.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Sat, 18 Sep 2021 05:34:08 -0700) Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> <83o8df0wrl.fsf@gnu.org> <83r1e0nroj.fsf@gnu.org> <8335q26uey.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 45379 Cc: stephen.berman@gmx.net, juri@linkov.net, handa@gnu.org, styang@fastmail.com, monnier@iro.umontreal.ca, larsi@gnus.org, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Stefan Kangas > Date: Sat, 18 Sep 2021 05:34:08 -0700 > Cc: stephen.berman@gmx.net, handa@gnu.org, juri@linkov.net, > styang@fastmail.com, monnier@iro.umontreal.ca, 45379@debbugs.gnu.org, > Lars Ingebrigtsen > > > key binding > > --- ------- > > > > 0 .. 9 digit-argument > > e tar-extract (currently shadowed by ‘View-exit’) > > f tar-extract > > > > C-d tar-flag-deleted > > RET tar-extract > > (this binding is currently shadowed) > > C-n tar-next-line > > C-p tar-previous-line > > SPC tar-next-line > > (this binding is currently shadowed) > > C tar-copy > > (this binding is currently shadowed) > > > > Note how the shadowing of 'e' is described with the command that > > shadows it, but the shadowing of RET, SPC, and 'C' isn't. Why is > > that? Is that a separate bug? > > It is a separate bug, I think. The "currently shadowed part" is new in > commit fb9326b45c76, but it was never fixed for the second case. Then I guess we can close this bug? From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 18 10:39:16 2021 Received: (at 45379) by debbugs.gnu.org; 18 Sep 2021 14:39:16 +0000 Received: from localhost ([127.0.0.1]:36415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRbUq-000894-0h for submit@debbugs.gnu.org; Sat, 18 Sep 2021 10:39:16 -0400 Received: from mail-pl1-f178.google.com ([209.85.214.178]:45858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRbUn-00088j-VS for 45379@debbugs.gnu.org; Sat, 18 Sep 2021 10:39:14 -0400 Received: by mail-pl1-f178.google.com with SMTP id n2so5518517plk.12 for <45379@debbugs.gnu.org>; Sat, 18 Sep 2021 07:39:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=swBd/vnS1hfZg+VV6zTtt4LYcKQ3nqMq1ZCfOFEMWc8=; b=KdiDCdNHCIEok4MU99brVzvyYhTDqcu9f2RhLeRvbeyEfM5c+cD06jA7akvjUiOwUI tXZDAqClLMXYXrRy15ir1mrO9cVstII/UiX2iZcX0vL4/IOtwk+FACWc+pHqx5vYNtDR nHwNPoqlLTRzII4qS4hjzmdf6vJtqhF1PCUe31otSlLAvY1kwtxdKUofrf7Q7BB9mCqo ZA7Ft9DGT4lhnx+I3KedFr07B53PVUGpyJdlOf50sAn+BN1VI99CqqVq0qvMeUjPfrZ4 WCsvaLknne6lcxjKuQOECmmGjqmYFaOA2OAnZw+ogq/YwU1syjhmZBEhaj9piBIpn6jg ZWDg== X-Gm-Message-State: AOAM533n1ZUW9WwxgK9RN+49TDvpZEr69W+GiIDJWCr9P6mFP3nuUvvY B+S6ekUiyCMjXjr6WDed1f2Rk2TP4AMNL3A1EN4= X-Google-Smtp-Source: ABdhPJz8YuxtNZ6YDUevRf9HnA8ZbwAjvg1CvgbSKhMyOVBdMUBE0kW9eQtxRXV3DSKmDUJhiQYqNOvicrZoDwRvBXU= X-Received: by 2002:a17:902:c412:b0:138:e681:fba4 with SMTP id k18-20020a170902c41200b00138e681fba4mr14367167plk.22.1631975948151; Sat, 18 Sep 2021 07:39:08 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 18 Sep 2021 07:39:07 -0700 From: Stefan Kangas In-Reply-To: <83sfy2584m.fsf@gnu.org> References: <02f717c6-dc96-4ba0-9117-2ef079ac556f@www.fastmail.com> <83o8df0wrl.fsf@gnu.org> <83r1e0nroj.fsf@gnu.org> <8335q26uey.fsf@gnu.org> <83sfy2584m.fsf@gnu.org> MIME-Version: 1.0 Date: Sat, 18 Sep 2021 07:39:07 -0700 Message-ID: Subject: Re: bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 45379 Cc: stephen.berman@gmx.net, juri@linkov.net, handa@gnu.org, styang@fastmail.com, monnier@iro.umontreal.ca, larsi@gnus.org, 45379@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) tags 45379 + fixed close 45379 28.1 thanks Eli Zaretskii writes: > Then I guess we can close this bug? I think so, yes, so I'm doing that now. If anyone is still seeing any issues related to this feel free to either reply back or just open a new bug. From unknown Sun Jun 15 08:42:07 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 17 Oct 2021 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator