From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#41200: Displaying a tooltip with x-show-tip gets very slow as more faces are defined Date: Fri, 15 May 2020 10:03:44 -0400 Message-ID: References: <8fd8896a-cd5c-66f4-4792-f65cac4dc4f5@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="98453"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 41200@debbugs.gnu.org To: =?UTF-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 15 16:05:12 2020 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 1jZaxc-000PPO-3P for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 May 2020 16:05:12 +0200 Original-Received: from localhost ([::1]:47644 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZaxb-0001ZB-64 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 May 2020 10:05:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZaxS-0001WB-Fw for bug-gnu-emacs@gnu.org; Fri, 15 May 2020 10:05:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54914) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZaxS-00007d-21 for bug-gnu-emacs@gnu.org; Fri, 15 May 2020 10:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jZaxR-0005VQ-Pt for bug-gnu-emacs@gnu.org; Fri, 15 May 2020 10:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 May 2020 14:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41200 X-GNU-PR-Package: emacs Original-Received: via spool by 41200-submit@debbugs.gnu.org id=B41200.158955144821072 (code B ref 41200); Fri, 15 May 2020 14:05:01 +0000 Original-Received: (at 41200) by debbugs.gnu.org; 15 May 2020 14:04:08 +0000 Original-Received: from localhost ([127.0.0.1]:38227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZawZ-0005Tn-Nk for submit@debbugs.gnu.org; Fri, 15 May 2020 10:04:08 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24153) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZawY-0005TO-Qr for 41200@debbugs.gnu.org; Fri, 15 May 2020 10:04:07 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 622558081D; Fri, 15 May 2020 10:04:01 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1BA87806A5; Fri, 15 May 2020 10:03:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1589551439; bh=9ga0gpLL3w551GG+c8W5y3aygVWhXJvr+LOlVL6HbAM=; h=From:To:Cc:Subject:Date:In-Reply-To:From; b=lcm78NmZtok75TjbTRnvee0j7OpXWQOkHai14UG1SOywV+f001u6ViEfG4oLQqQMK jAykrUpv0+L+2dF1qCetYax7InP3Z0Tj7BSBYf4GQOvM/RAheq5b/X/0bG36GsVlQB uWhmuRT3Uogv9knthKmk1SiBWCb4JYuuFEZQDNuc/nhvVZu4o0AL2viKlNlFQqAdsv KK6Qq0pQLBcDVaj6CFt1oSGcWJXR9H7QUmowxDSQ/z7KCvI87EeXvJuW0RnNcecWD9 9Kp/LaZIWOO+7yDJxnzyu8nagDs5jBrcbVe3S1M+/MiTOyffq4G1mY2bKBqmmhWike 00jtxRNO5qr1w== Original-Received: from alfajor (unknown [216.154.3.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4580A120736; Fri, 15 May 2020 10:03:58 -0400 (EDT) In-Reply-To: nobody's message of "(unknown date)" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:180332 Archived-At: > Indeed, you're completely right; thanks! Replacing face_alist and > Vface_new_frame_defaults with hash tables makes the worst example > about 10 times faster, and with that change tooltips now take 30 to > 50ms to display instead of 500-600ms in my real-life use case (my > usual config). I have attached a patch. Oh, this is great, makes a very noticeable difference. I'm hoping it can make it into Emacs-27.1, tho it is probably rather late for such a significant change. > * I removed the function frame-face-alist and changed the type of the > variable face-new-frame-defaults. Both were documented as internal. > Should I add an ELisp implementation of frame-face-alist for > compatibility? (It wouldn't be a perfect shim, since modifying its > return value wouldn't do the same). For face-new-frame-defaults it's > a bit trickier, since the variable now holds a hash table. > Should I change its name to make the change obvious, at least? The variable's name did not say "alist", so I don't see a need to change it from that point of view. But I think it deserves a "--" since it's supposed to be internal. A quick grep revealed: elpa/packages/context-coloring/fixtures/benchmark/faces.el: (mapcar #'car face-new-frame-defaults)) That doesn't seem very serious, but I haven't grep'd the MELPA packages. I saw no such comparable use of `frame-face-alist` in the wild. > * The name face_hash isn't ideal, since there's already a distinct > notion of face hashes (hash codes). Can you think of a better name? Yes: it's not a hash, it's a table. I think the better names refer to the "conceptual" type rather than the specific implementation type, so I prefer "map" or "table" to "hash", "alist", "obarray", and whatnot. > - command-execute 454 47% [...] > - face-set-after-frame-default 387 40% > - face-spec-recalc 374 39% > - make-face-x-resource-internal 296 30% > - set-face-attributes-from-resources 273 28% > - set-face-attribute-from-resource 219 22% [...] > - command-execute 768 80% [...] > - face-set-after-frame-default 674 70% > - face-spec-recalc 660 69% > - face-spec-set-2 350 36% > - apply 348 36% > - set-face-attribute 342 35% > - internal-set-lisp-face-attribute 342 35% > - frame-set-background-mode 331 34% > - face-spec-recalc 284 29% > - make-face-x-resource-internal 235 24% Both of those profiles suggest that most of the time is still spent in `face-spec-recalc`, so it would be worth trying harder to avoid calling it or to speed it up somehow (presumably with some better memozing/caching). The first profile also suggests that we spend too much time in `make-face-x-resource-internal`. What caught my eye in the second profile is the fact that we call `face-spec-recalc` recursively. I suspect that recursion is not desired. Stefan PS: Maybe another way to speed this up is to do the `face-spec-recalc` lazily (i.e. only when we encounter the face during redisplay), but that's probably harder to do and not as good (since it will still be slow in the case where the frame happens to display hundreds of faces).