Huge slowdown on emacs 27.1

[jwnki]

Hi, thanks for this pretty package!

I have recently updated to emacs 27.1 and using org-superstar-mode renders emacs unusable with bigger org files. Even for smaller files you can see the effect particularly when moving between headings or folding/unfolding. Adding
(setq inhibit-compacting-font-caches t) to init.el didn't help.
I first experienced this using spacemacs (see this issue) something similar happens also on doom-emacs (issue).
I am not sure to what extent this is caused by org-superstar because on spacemacs a similar slowdown could be observed when visiting a huge org file with some "non-standard" unicode glyphs without org-superstar enabled. But this definitely happens also on vanilla 27.1 with just org-superstar.

I am attaching profile reports for vanilla 27.1. These were generated by opening the org file pasted below, doing M-x profiler-start, then M-x org-superstar-mode, moving the cursor between headings, folding/unfolding, and finally M-x profiler-stop.

The org file:

* heading1
text
** heading2
text2

superstar_profilecpu.txt
superstar_profilemem.txt

M-x emacs-version: GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.21, cairo version 1.16.0)

[integral-dw]

Hi, I'll have to look more into it. In the meantime, could you do me a favor and check if the issue persists in Org when you insert the characters in question literally? As in, if you open a large file full of actual special characters, does the problem persist in vanilla Emacs? If Spacemacs experiences this problem then maybe vanilla does as well.

[jwnki]

Sure! Actually this was a great suggestion, thanks.
Even pasting these four characters into scratch buffer ("◉" "○" "✸" "✿") causes vanilla emacs to hang for a short while, and makes it consume 100% cpu. Opening a file containing these takes longer than a minute. I guess this means it's not caused by org-superstar. Also I just realized that these glyphs are not a part of the font I am using in emacs, so probably that's the problem? That emacs has to come up with some other way of rendering these instead of just taking them from the font?
I'll see what happens with different fonts.

Thanks for your help I think you can close this, even if this persists with a different font it's clearly emacs fault.

[integral-dw]

No prob. You can investigate the font at point (together with many other properties of the text) using C-u C-x =. I'd love to hear what font(s) may cause issues, it would certainly help others with the same issue.

[jwnki]

With pleasure :)
I am using Source Code Pro. What helped me to actually solve the issue was to install unicode-fonts package and follow the guide in the repository of the package: https://github.com/rolandwalker/unicode-fonts

I am attaching the output of C-u C-x = on the two glyphs: the first one was working as can be seen from ftcrhb:-ADBO-Source Code Pro, the second one wasn't (ftcrhb:-Misc-Fixed-normal). Emacs 26 would just silently drop the second one while the 27 would hang for a while but render it eventually (but as a slightly different symbol, a small star).

fontinfo.txt

[integral-dw]

Wonderful, thank you for your time! I will try and see if I can find a way to explore that issue, and if not, I can at least try to curate a list of "cursed fonts" so to say. :)