[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00e

From: Clément Pit--Claudel
Subject: bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00ef86fac835b5fac (Apr 2014).
Date: Thu, 16 Mar 2017 17:23:13 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 2017-03-16 11:27, Eli Zaretskii wrote:
>>> You should instead specify the scripts which the fonts supports well.
>> Ok — but why wasn't it slow in 24.3?
> That's the question about the significance of the zero_vector in the
> font-cache, the patch you want to apply.  I'm still struggling with
> understanding why it speeds up the font search.

Got it, thanks.  I don't know whether that'll be useful, but I uploaded a 
pre-built virtual machine to 
https://people.csail.mit.edu/cpitcla/emacs-bug-21028.ova ; maybe this is a 
viable option (it should be much easier to download a VM than to rebuild one, I 

It was produced using the instructions that I posted earlier.  On that machine, 
here are the times I get for the benchmark you posted earlier:

address@hidden ~ $ time emacs/emacs-25.1/src/emacs -Q --eval "(progn 
(set-fontset-font \"fontset-startup\" 'unicode \"Ubuntu Mono\" nil) 
(set-fontset-font \"fontset-startup\" 'unicode \"Symbola\" nil 'append) 
(dotimes (_ 5000) (insert (make-string 20 8658) \"\n\")) (goto-char 
(point-min)) (sit-for 0) (condition-case nil (while t (scroll-up) (sit-for 0)) 
(error nil)) (run-with-idle-timer 0 nil #'kill-emacs))"
real    5m54.574s
user    0m54.612s
sys     1m17.496s

I loaded this VM on a different machine and confirmed that I could reproduce 
the problem in the guest (2s without fontset declarations, and >4m with fontset 
declarations).  I wasn't able to reproduce the bug on the host, though, 
mirroring your unsuccessful reproduction attempts.  I wonder if something's 
wrong in Linux Mint… that host wasn't running Mint.

Maybe this pre-built VM can help reproduce, and thus understand, the underlying 
problem?  Otherwise, maybe you could recommend a resource that I should look 
into to debug the problem myself locally?

>> And why does the number of fonts matter,
>> if I'm only adding one (Symbola) with 'unicode?
> Any font has several variants, and they are all checked.  Moreover,
> checking too many fonts conses a lot of Lisp data, which is likely to
> trigger GC, which is likely to throw away font caches, which will then
> require us to check those fonts again.

Thanks, understood.

>>> That shouldn't be a problem in Emacs 25: it by default uses the
>>> default face's font for any punctuation and symbol characters for
>>> which the font has glyphs, even if the fontset specifies a different
>>> font for punctuation and symbol blocks.
>> Neat.  Though of course that doesn't help for Emacs < 24.
> Users who care about fonts and exotic characters shouldn't stay with
> Emacs 24.

Understood as well.

>> In these fast example I'm still adding Symbola with 'unicode — but
>> adding Ubuntu Mono with 'latin.
> Ubuntu Mono _is_ the problem.  Symbola has very good coverage of
> almost all Unicode blocks, so it is not the problem.

Ok, I think I understand better now.  But I'm still confused: why would the 
following be slow, then?

    25.1/src/emacs -Q --eval "(set-fontset-font \"fontset-default\" 'unicode 
(font-spec :name \"Symbola\") nil 'prepend)"

To clarify: it isn't slow with the example of plenty of ⇒ characters, but it's 
still slow if I use a more diverse set of symbols or letters, like e.g.


So although I think we're converging to a fix for my font config and the use 
case where Symbola covers everything, there's still an underlying problem that 
would be great to fix (and your patch does fix it).

>>> That could sometimes be the case, but I have found that in some cases
>>> omitting the registry for characters beyond Latin-1 can be a major
>>> setback.  So I recommend to always use it.
>> Ok.  Could Emacs not infer it?
> I think Emacs still goes by the XLFD rules, which require iso8859-1 be
> the default.  I don't know how important it is to keep that
> compatibility.


>>> Moreover, Emacs cannot compose glyphs that come from different fonts,
>>> so you will sometimes see decomposed display if you request a font for
>>> scripts where its support is incomplete.  I think this is an important
>>> factor for users of prettify-symbols-mode in particular.
>> Why? prettify-symbols-mode composes strings (typically) into single 
>> characters, 
>> so why would this matter?
> I imagine that prettify-symbols-mode is not limited to single existing
> characters, but if it is, this issue is indeed not relevant to that
> mode.

The basic interface that it provides is indeed limited to that, so you can 
trick it by adding arbitrary composition strings to prettify-symbols-alist.

>> * Download and install fontforge.  Figure out which ranges the math font
>> support, and all the characters that it supports that are not punctuation or 
>> symbols, too
> Not needed, as long as the default font is set up via
> default-frame-alist.

Ah, I see.

> What happens if you don't do this?  Which font is used for math
> symbols?  Or are the problems with symbols other than math symbols?
> IOW, I don't understand fully why you need to set up XITS Math in the
> fontset, what is missing/incorrect/ugly if you don't?

I think this is due to my not explaining it properly, or trying to hard to make 
minimal examples.  In can answer separately for myself and for the other user 
configurations I've looked at.

For myself, it's a matter of monospace fonts: that is, I want all characters to 
occupy the same width, so I don't use Symbola: instead, I use a version of XITS 
Math edited with FontForge to have equal widths for all characters.  I also 
prefer as many characters to be displayed by the same font.

For other users, we had cases were Emacs displayed an empty rectangle until we 
added an explicit set-fontset-font with Symbola.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]