bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00ef86fac835b5fac (Apr 2014).

[Eli Zaretskii <eliz@gnu.org>]

> 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.