From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: Memory leak Date: Mon, 19 May 2008 17:05:42 +0900 Message-ID: References: <85lk2b1829.fsf@lola.goethe.zz> <482CD48E.3020601@gmail.com> <482D8332.5030908@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1211184644 2684 80.91.229.12 (19 May 2008 08:10:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 May 2008 08:10:44 +0000 (UTC) Cc: eliz@gnu.org, lennart.borgman@gmail.com, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Jason Rumney Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 19 10:11:22 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Jy0So-0002e9-6V for ged-emacs-devel@m.gmane.org; Mon, 19 May 2008 10:11:22 +0200 Original-Received: from localhost ([127.0.0.1]:34500 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jy0S4-0001rn-9m for ged-emacs-devel@m.gmane.org; Mon, 19 May 2008 04:10:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jy0Rz-0001rc-Vx for emacs-devel@gnu.org; Mon, 19 May 2008 04:10:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jy0Ry-0001rQ-Ay for emacs-devel@gnu.org; Mon, 19 May 2008 04:10:31 -0400 Original-Received: from [199.232.76.173] (port=59552 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jy0Ry-0001rN-7A for emacs-devel@gnu.org; Mon, 19 May 2008 04:10:30 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:44063) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jy0Rm-0006ki-TC; Mon, 19 May 2008 04:10:19 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jy0Rk-0004Li-MO; Mon, 19 May 2008 04:10:17 -0400 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id m4J85u44011571; Mon, 19 May 2008 17:06:00 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id m4J85tMh003499; Mon, 19 May 2008 17:05:55 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp4.aist.go.jp with ESMTP id m4J85gbl007922; Mon, 19 May 2008 17:05:42 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken.m17n.org with local (Exim 4.69) (envelope-from ) id 1Jy0NK-0000I6-BP; Mon, 19 May 2008 17:05:42 +0900 In-reply-to: <482D8332.5030908@gnu.org> (message from Jason Rumney on Fri, 16 May 2008 13:50:58 +0100) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-detected-kernel: by mx20.gnu.org: Solaris 8 (1) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:97380 Archived-At: In article <482D8332.5030908@gnu.org>, Jason Rumney writes: > 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). I've just installed a fix in font-cache handling. Now, even when I create many new frames, the memory usage doesn't increase that much. Though it still increases several handreds K-bytes each time a new frame is created, and it is not reduced when I delete the frames. So, I think there still be a problem somewhere. FYI, when I compile Emacs without gtk, the amount of (non-freed) memory increase becomes smaller. > 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. I remember that I modified x_draw_glyph_string for such a font-backend as xft that can't do foreground-only drawing because of antialiasing, which increases the count of overhang-checking. Perhaps we should study the code of draw_glyphs and x_draw_glyph_string and find a solution. --- Kenichi Handa handa@ni.aist.go.jp