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

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, 21028@debbugs.gnu.org
> From: Clément Pit--Claudel <clement.pitclaudel@live.com>
> Date: Thu, 3 Mar 2016 00:33:42 -0700
> 
> I've looked further into this. Comparing the profiles, there seems to be two 
> significant differences:
> 
> 1. ‘deliver_user_signal’ gets called constantly in the slow case, with many 
> calls to ‘x_catch_errors_with_handler’, ‘x_catch_errors_with_handler’, 
> ‘x_had_errors_p’, and ‘x_uncatch_errors’; there are few to no such calls in 
> the 
> fast case.

Not sure this is related.

> 2. font_list_entities constantly calls xfont_list in the slow case, but not 
> in 
> the fast case:

Most probably because in the "fast" case it finds the empty vector in
the cache, and thus avoids the costly call to the font driver's 'list'
method.

> Here is the new code:
> 
>     val = driver_list->driver->list (f, scratch_font_spec);
>     if (!NILP (val))
>       {
>         Lisp_Object copy = copy_font_spec (scratch_font_spec);
> 
>         val = Fvconcat (1, &val);
>         ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
>         XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
>       }
> 
> The commit message didn't explain why it was a good thing to not add an empty 
> vector to the cache.

Yes, it did, see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17125#32:
the empty vector was causing an error when creating a new frame via
emacsclient.

> I'm a bit stuck at this point. I'm not sure how 1 and 2 are connected. 
> Suggestions?

Like I said, I'm not sure 1 is of any immediate concern to us.

The only way forward I see is to reproduce the problem described in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17125#26 and in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17125#29, in the "fast"
case (i.e. without the changes that fixed that bug), and then look for
a different solution for that problem.  If you can reproduce that,
please step through x_default_font_parameter and x_default_parameter,
and tell how does the empty vector in the cache come into play.  Then
we can try some other solution for that.

Thanks.