From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: Memory leak Date: Fri, 16 May 2008 13:50:58 +0100 Message-ID: <482D8332.5030908@gnu.org> References: <85lk2b1829.fsf@lola.goethe.zz> <482CD48E.3020601@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1210942308 3371 80.91.229.12 (16 May 2008 12:51:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 May 2008 12:51:48 +0000 (UTC) Cc: "Lennart Borgman \(gmail\)" , monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 16 14:52:25 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 1JwzPt-000705-0L for ged-emacs-devel@m.gmane.org; Fri, 16 May 2008 14:52:09 +0200 Original-Received: from localhost ([127.0.0.1]:46233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JwzP9-0005Hi-DD for ged-emacs-devel@m.gmane.org; Fri, 16 May 2008 08:51:23 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JwzOu-00057n-LH for emacs-devel@gnu.org; Fri, 16 May 2008 08:51:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JwzOu-00057N-7o for emacs-devel@gnu.org; Fri, 16 May 2008 08:51:08 -0400 Original-Received: from [199.232.76.173] (port=46054 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JwzOt-00057C-Tj for emacs-devel@gnu.org; Fri, 16 May 2008 08:51:07 -0400 Original-Received: from mk-outboundfilter-5-a-2.mail.uk.tiscali.com ([212.74.114.4]:17836) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JwzOq-0001du-FH; Fri, 16 May 2008 08:51:04 -0400 Original-X-Trace: 28389927/mk-outboundfilter-5.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/83.67.23.108 X-SBRS: None X-RemoteIP: 83.67.23.108 X-IP-MAIL-FROM: jasonr@gnu.org X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4EAF8fLUhTQxds/2dsb2JhbACBVaxC X-IronPort-AV: E=Sophos;i="4.27,497,1204502400"; d="scan'208";a="28389927" X-IP-Direction: IN Original-Received: from i-83-67-23-108.freedom2surf.net (HELO wanchan.jasonrumney.net) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP; 16 May 2008 13:51:02 +0100 Original-Received: from [192.168.249.27] (chiko.jasonrumney.net [192.168.249.27]) by wanchan.jasonrumney.net (Postfix) with ESMTP id 156F415B9; Fri, 16 May 2008 13:51:02 +0100 (BST) User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) In-Reply-To: X-Enigmail-Version: 0.95.6 OpenPGP: id=8086879D X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:97268 Archived-At: 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.