From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#71454: 30.0.50; Performance issues with font selection Date: Mon, 10 Jun 2024 14:53:36 +0300 Message-ID: <867cex9fpb.fsf@gnu.org> References: <87v82h6a33.fsf@jeremybryant.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27783"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jporterbugs@gmail.com, jb@jeremybryant.net, 71454@debbugs.gnu.org To: Kai Ma Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 10 13:59:32 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sGdgR-0006xd-Uy for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Jun 2024 13:59:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sGdfj-0006o1-Um; Mon, 10 Jun 2024 07:58:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGdfi-0006nF-LJ for bug-gnu-emacs@gnu.org; Mon, 10 Jun 2024 07:58:46 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sGdfi-0000Il-D1 for bug-gnu-emacs@gnu.org; Mon, 10 Jun 2024 07:58:46 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sGdfz-00087Q-9C for bug-gnu-emacs@gnu.org; Mon, 10 Jun 2024 07:59:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Jun 2024 11:59:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71454 X-GNU-PR-Package: emacs Original-Received: via spool by 71454-submit@debbugs.gnu.org id=B71454.171802071031080 (code B ref 71454); Mon, 10 Jun 2024 11:59:03 +0000 Original-Received: (at 71454) by debbugs.gnu.org; 10 Jun 2024 11:58:30 +0000 Original-Received: from localhost ([127.0.0.1]:57392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sGdfR-000856-OM for submit@debbugs.gnu.org; Mon, 10 Jun 2024 07:58:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sGdfQ-00084R-66; Mon, 10 Jun 2024 07:58:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGdal-0007mk-5b; Mon, 10 Jun 2024 07:53:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Z/yiZ3K0bc+FDCRR6iHb4MqKID+8oR1J1UUeVx9Hnx4=; b=liK2Gplensr0KLoCLz71 XEz45hKIyKsKbUdAsigrfH8oanwpQGXnVgX+0s4L2eKjht+FN8SEsG/xDyogO0viHbclT0k0foyKL FzDX27e+OEg+pra/Wu5+mGP1J6h0tlAyOOw6IoAW4F+qWMG9fbClY6ZvTuSCa1+0sr/sHO0+//AwI 27zIZ+uhxj/ZrEwK1iUYBqhFAUDLKv3RSnjhG/rjGhHsYhDnunXTFcnXGOUMZHtTzz7r1FxEaW26G w5tTodqj5TO8I3nMLy63LsbGsW/Xzo762CqWz8aA3b+CX1ebYLzO8Vt9DF6EpkIjk9JS6PkvteyyB ii9hvhrNnM6gTw==; In-Reply-To: (message from Kai Ma on Mon, 10 Jun 2024 04:18:08 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287025 Archived-At: severity 71454 wishlist thanks > Cc: Jeremy Bryant , 71454@debbugs.gnu.org > From: Kai Ma > Date: Mon, 10 Jun 2024 04:18:08 +0200 > > > On Jun 10, 2024, at 01:10, Jim Porter wrote: > > > > On 6/9/2024 3:17 PM, Kai Ma wrote: > >>> On Jun 10, 2024, at 00:10, Jeremy Bryant wrote: > >>> > >>> Would you be able to provide a self-contained series of steps starting > >>> from emacs -Q? > >> On my machine it is extremely easy to reproduce by simply: > >> 1. emacs -Q > >> 2. Switch to *scratch* > >> 3. Copy the provided text into *scratch* > >> 4. Emacs will freeze for 17 seconds or so, and it cannot be interrupted by C-g > > > > Is this on MS-Windows, by chance? Using a different set of steps, I can reproduce this issue on MS-Windows (Emacs 29.3), but not on GNU/Linux. Here's what I did: > > > > emacs -Q > > C-h v comint-password-prompt-regexp RET > > > I’m using macOS. I apologize for not adding this info to my original report. > > And yes, I can also reproduce the issue with C-h v comint-password-prompt-regexp RET AFAICT, the problematic part of comint-password-prompt-regexp is this: गुप्तशब्द\\|शब्दकूट\\|গুপ্তশব্দ\\|পাসওয়ার্ড\\|ਪਾਸਵਰਡ\\|પાસવર્ડ\\|ପ୍ରବେଶ ସଙ୍କେତ\\|கடவுச்சொல்\\|సంకేతపదము\\|ಗುಪ್ತಪದ\\|അടയാളവാക്ക്\\|රහස්පදය This has nothing to do with the number of fonts installed on the system, nor with how Emacs searches for fonts, nor even with the fonts themselves. On my system, all of the characters above are displayed using the same single font. And yet, even if I insert just a single character of those, which causes Emacs to find and load that font, pasting the rest of the string takes several seconds in an unoptimized build (I expect it to take about 2 sec or less in an optimized build). Note that if you then paste the same string over and over again, the display is instantaneous. My crystal ball says that the expensive part here is character composition. The above characters belong to scripts that require extensive composition rules, take a look at indian.el and its complex regexps. Displaying those characters requires the display code to examine all those regexps, to find the largest composable sequence, then generate the compositions by calling into Lisp, which then calls back into C where we call HarfBuzz to produce the font glyphs for the compositions. This is expensive, and so Emacs caches each composition for further use, which explains why subsequent pastes are much faster. IOW, this is a price we pay for the fact that we make character compositions infinitely customizable on the Lisp level. So far, I see no bug here. Of course, if someone wants to work on redesign of how Emacs handles character composition, and as part of such a redesign will make the process much faster, that would be very welcome.