Re: reducing equality tests in displaying text

[Kenichi Handa]

In article <address@hidden>, YAMAMOTO Mitsuharu <address@hidden> writes:

> I experimented with some performance tool and noticed that there were
> frequent equality tests in displaying text.  I think most of them can
> safely be reduced.

Thank you for the report.

> 1. Each call of assoc_no_quit (charset,_encoding_charset_alist) in
>    fontset.c can be replaced with assq_no_quit because
>    Vfont_encoding_charset_alist is a symbol-keyed alist.

Yes, just fixed.

> 2. Also in fontset.c:

>    472          if (c >= 0)
>    473            font_group = char_table_ref_and_range (base_fontset, c, 
> &from, &to);
>    474          else
>    475            font_group = FONTSET_FALLBACK (base_fontset);
>    476          if (NILP (font_group))
>    477            return Qnil;

>    If `font_group' becomes Qnil in line 473, `from' and `to' are not
>    used at all.  So the most of the task of char_table_ref_and_range
>    is wasted for this case.  Because font_group == Qnil case happens
>    frequently, the char_table_ref_and_range call should be avoided for
>    this case.

When font_group is Qnil, in most cases, SUB_CHAR_TABLE_P
(table) is zero.  Thus the calculation of FROM and TO must
not be that slow.  Did you really see the bottle-neck of the
performance here?

> 3. Despite its argument name, `has_char' functions in font backend
>    drivers are mostly called for a font object instead of a font
>    entity.  Some font backend drivers could make use of this fact:
>    e.g., ftfont_has_char can avoid frequent assoc_no_quit calls if
>    struct ft_font has a reference to fc_charset in ft_face_cache.

I've just fixed ftfont_has_char to use FT_Get_Char_Index
directly.

> BTW, I suspect Ffontset_font is broken.  I couldn't get any meaningful
> result from (fontset-font t ?a), for example.

I fixed it too.

---
Kenichi Handa
address@hidden