From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
Cc: 41200@debbugs.gnu.org
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 [thread overview]
Message-ID: <jwvlfltl3qa.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: nobody's message of "(unknown date)"
> 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).
next prev parent reply other threads:[~2020-05-15 14:03 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 4:30 bug#41200: Displaying a tooltip with x-show-tip gets very slow as more faces are defined Clément Pit-Claudel
2020-05-12 6:42 ` martin rudalics
2020-05-12 11:30 ` Clément Pit-Claudel
2020-05-12 15:12 ` martin rudalics
2020-05-12 17:19 ` Clément Pit-Claudel
2020-05-12 17:42 ` martin rudalics
2020-05-12 17:58 ` Eli Zaretskii
2020-05-13 14:58 ` martin rudalics
2020-05-12 15:27 ` Eli Zaretskii
2020-05-13 2:41 ` Clément Pit-Claudel
2020-05-13 14:58 ` martin rudalics
2020-05-13 15:13 ` Clément Pit-Claudel
2020-05-13 17:42 ` martin rudalics
2020-05-15 11:05 ` Eli Zaretskii
2020-05-15 14:59 ` Clément Pit-Claudel
2020-05-15 15:17 ` Eli Zaretskii
2020-05-15 15:33 ` Noam Postavsky
2020-05-15 16:22 ` Clément Pit-Claudel
2020-05-15 17:28 ` Eli Zaretskii
2020-05-15 18:50 ` Clément Pit-Claudel
2020-05-15 19:05 ` Eli Zaretskii
2020-05-15 19:23 ` Clément Pit-Claudel
2020-05-15 19:38 ` Eli Zaretskii
2020-05-15 19:52 ` Clément Pit-Claudel
2020-05-16 23:03 ` Juri Linkov
2020-05-16 23:43 ` Clément Pit-Claudel
2020-05-17 21:59 ` Juri Linkov
2020-05-18 1:19 ` Clément Pit-Claudel
2020-05-19 21:48 ` Juri Linkov
[not found] ` <83a71z135p.fsf@gnu.org>
2020-05-23 22:47 ` Juri Linkov
2020-05-24 2:33 ` Eli Zaretskii
2020-05-24 21:50 ` Juri Linkov
2020-06-08 0:21 ` Juri Linkov
2020-06-20 7:47 ` Eli Zaretskii
2020-06-20 16:55 ` Clément Pit-Claudel
2020-07-04 7:58 ` Eli Zaretskii
2020-09-13 2:53 ` Benson Chu
2020-05-15 14:03 ` Stefan Monnier [this message]
2020-05-15 14:34 ` Eli Zaretskii
2020-05-15 19:10 ` Clément Pit-Claudel
2020-05-15 21:23 ` Stefan Monnier
2020-05-16 8:45 ` martin rudalics
2021-04-06 6:35 ` Jashank Jeremy
2021-04-06 12:30 ` Eli Zaretskii
2021-04-06 15:07 ` Clément Pit-Claudel
2021-04-06 15:50 ` Eli Zaretskii
2021-04-23 3:56 ` Stefan Monnier
2021-05-12 20:29 ` Lars Ingebrigtsen
2021-05-13 3:56 ` Jashank Jeremy
2021-05-13 9:15 ` Lars Ingebrigtsen
2021-05-13 23:26 ` Jashank Jeremy
2021-06-12 12:15 ` Lars Ingebrigtsen
2021-06-13 3:19 ` Richard Stallman
2021-07-06 12:41 ` Aaron Jensen
2021-07-21 14:02 ` Lars Ingebrigtsen
2021-07-21 14:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-21 14:32 ` Clément Pit-Claudel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvlfltl3qa.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=41200@debbugs.gnu.org \
--cc=cpitclaudel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).