Re: Memory leak

[Jason Rumney]

Eli Zaretskii wrote:
> With today's CVS on w32, the memory grows by ~900KB with each new
> frame I create, and that memory is not released when the frame and its
> buffer are deleted.
>   


If the leak is coming from the font cache, then I wouldn't expect it to 
be released when the frame is deleted, as the font cache is shared 
between all frames on w32 (and I think between all frames on the same 
display on X). Stefan is seeing 10x the increase as you are on Windows, 
which could be explained by xft loading fonts into Emacs's process 
space, while on Windows the font itself stays in system owned memory, 
and only Emacs's internal info that it associates with the font 
contributes to the growth. That also points to fonts being responsible 
(though circumstantial).

A while ago I noticed w32font_open being called multiple times for the 
same font, so I suspect that we may be overlooking the font cache in 
places and reopening fonts when we could be reusing an existing font.

There is another similar problem when we get text extents - each redraw 
cycle can call w32font_text_extents a number of times for the same 
glyph_string (from compute_glyph_string_overhangs, left_overwriting and 
right_overwriting in quick succession in draw_glyphs, with nested 
compute_overhangs_and_x within some of the if statements that cause 
extra calls for preceding and following glyph_strings if there is 
overhang, which there often is with antialising enabled). Perhaps this 
operation is cheap with the X font backends, but on Windows it is 
expensive (even with caching of metrics), and I suspect this is a major 
cause of the slowdown reported by Windows users.