[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00e
From: |
Eli Zaretskii |
Subject: |
bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00ef86fac835b5fac (Apr 2014). |
Date: |
Sun, 16 Apr 2017 10:48:04 +0300 |
> Date: Thu, 16 Mar 2017 17:27:09 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 21028@debbugs.gnu.org
>
> > Cc: 21028@debbugs.gnu.org
> > From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> > Date: Wed, 15 Mar 2017 16:46:33 -0400
> >
> > > The problem here is that opening a font and looking up a character is
> > > very expensive, certainly when there are hundreds of fonts installed.
> > > So Emacs filters the fonts according to the scripts they claim to
> > > support, and only opens those which appear to be valid candidates for
> > > the script of the character it needs to display. By using 'unicode as
> > > the script when you set up your fontset, you actually trip Emacs by
> > > telling it to try this font for every character it needs to display.
> > > 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.
After looking at the code and discussing with Handa-san, I concluded
that we should restore putting the zero_vector in the font-cache when
no fonts matching a spec were found.
So I've reverted part of the changes introduced during fixing
bug#17125, and I'm marking this bug done. If these changes cause some
trouble, we will have to debug that when the problems are reported.
Thanks.
- bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00ef86fac835b5fac (Apr 2014).,
Eli Zaretskii <=