bug#15876: 24.3.50; Highly degraded performance between rev 114715 and 115006

[Dmitry Antipov]

On 12/05/2013 09:36 PM, Eli Zaretskii wrote:

> Yes, I see the same on Windows.  However, I'm not sure we are looking
> at objects we should be looking at.  The ones your code traces are
> font objects.  By contrast, the entries in the font caches are cons
> cells like this:
>
>     (font-spec . [font-entity1 font-entity2 ...])
>
> IOW, I think we should be tracing font-specs and font-entities, not
> font objects.

IMO the real problem is that redisplay sometimes isn't clever enough about 
requesting
font for the particular character (0x25b7 in our case):

#0  font_make_entity () at ../../trunk/src/font.c:169
#1  0x00000000005a8a3f in xfont_list_pattern (display=display@entry=0x1379260,
    pattern=pattern@entry=0x7fffffff7730 
"-adobe-courier-*-*-*--*-*-*-*-*-*-iso10646-1", 
registry=registry@entry=12260082,
    script=script@entry=12084946) at ../../trunk/src/xfont.c:403
#2  0x00000000005a9059 in xfont_list (f=<optimized out>, spec=12183525) at 
../../trunk/src/xfont.c:515
#3  0x0000000000563193 in font_list_entities (f=f@entry=0x111fd58, 
spec=spec@entry=15986301) at ../../trunk/src/font.c:2735
#4  0x0000000000563b42 in font_find_for_lface (f=f@entry=0x111fd58, 
attrs=attrs@entry=0x16b9510, spec=<optimized out>,
    c=c@entry=9655) at ../../trunk/src/font.c:3206
#5  0x00000000005a9d44 in fontset_find_font (fontset=18338269, c=c@entry=9655, 
face=face@entry=0x16b9510, id=id@entry=-1,
    fallback=fallback@entry=false) at ../../trunk/src/fontset.c:681
#6  0x00000000005aa210 in fontset_font (fontset=fontset@entry=17988749, 
c=c@entry=9655, face=face@entry=0x16b9510, id=-1)
    at ../../trunk/src/fontset.c:754
#7  0x00000000005aacb2 in face_for_char (f=0x111fd58, face=face@entry=0x16b9510, c=9655, 
pos=<optimized out>, object=<optimized out>)
    at ../../trunk/src/fontset.c:978
#8  0x000000000043cb45 in get_next_display_element (it=it@entry=0x7fffffff97f0) 
at ../../trunk/src/xdisp.c:6997
#9  0x0000000000441bc3 in display_line (it=it@entry=0x7fffffff97f0) at 
../../trunk/src/xdisp.c:19593
#10 0x000000000044506a in try_window (window=window@entry=17964077, pos=..., 
flags=flags@entry=1) at ../../trunk/src/xdisp.c:16505
#11 0x000000000045ab57 in redisplay_window (window=17964077, 
just_this_one_p=just_this_one_p@entry=false)
    at ../../trunk/src/xdisp.c:16022
#12 0x000000000045cbf3 in redisplay_window_0 (window=window@entry=17964077) at 
../../trunk/src/xdisp.c:14023
#13 0x000000000054d216 in internal_condition_case_1 (bfun=bfun@entry=0x45cbc0 
<redisplay_window_0>, arg=17964077,
    handlers=<optimized out>, hfun=hfun@entry=0x4290a0 
<redisplay_window_error>) at ../../trunk/src/eval.c:1368
#14 0x000000000042d8ce in redisplay_windows (window=17964077) at 
../../trunk/src/xdisp.c:14003
#15 0x000000000044a121 in redisplay_internal () at ../../trunk/src/xdisp.c:13602

Such a request produces a lot of font-entity objects, which are not needed (and 
becomes
reachable only via font cache) after the "best match" font is selected for the 
particular
character. Next, if font loading is too memory-intensive and gc_cons_threshold 
was hit, GC
clears font cache. Next cursor movement triggers redisplay, which in turn asks for 
the "best
match" for 0x25b7 again. If font cache is never cleared, this is acceptable 
because all possible
matches (represented as a vector of font-entities) are cached. But, if font 
cache is cleared,
font_list_entities calls to driver->list function, which creates a lot of 
font-entities again,
etc., etc.

Until we have somewhat smarter redisplay, possible solution is to clear font 
cache when it
becomes larger than some specified size rather than at each GC. Now I have the 
virtual machine
with Windows 7 installed, and this fix looks reasonable for me. Could you also 
please try it?

Dmitry

font_cache_size_bug15876.patch
Description: Text Data