From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bugs Subject: bug#3208: 23.0.93; Memory full / crash when displaying lots of characters from a large font (like Arial Unicode or Code2000) which is not explicitly selected (on Win32) Date: Wed, 24 Jun 2009 20:45:35 +0900 Message-ID: References: <49FF3340.2040008@gmx.de> <4A005A64.5050908@gnu.org> <4A3F1B05.7030105@gnu.org> <4A3F7058.902@gnu.org> <4A3F81AC.1070404@gnu.org> <4A4201EF.7000901@gnu.org> Reply-To: Kenichi Handa , 3208@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1245844731 19622 80.91.229.12 (24 Jun 2009 11:58:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jun 2009 11:58:51 +0000 (UTC) Cc: schierlm@gmx.de, 3208@emacsbugs.donarmstrong.com To: Jason Rumney Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 24 13:58:44 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MJR7j-0006P5-Q8 for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jun 2009 13:58:44 +0200 Original-Received: from localhost ([127.0.0.1]:38640 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJR7j-0005LZ-54 for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jun 2009 07:58:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJR6Z-0004z8-R4 for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2009 07:57:31 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJR6U-0004xj-Cu for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2009 07:57:31 -0400 Original-Received: from [199.232.76.173] (port=58295 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJR6U-0004xa-33 for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2009 07:57:26 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:42249) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJR6T-0006eB-By for bug-gnu-emacs@gnu.org; Wed, 24 Jun 2009 07:57:25 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5OBvMfa011918; Wed, 24 Jun 2009 04:57:23 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n5OBo4kh010413; Wed, 24 Jun 2009 04:50:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: Kenichi Handa Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs , owner@emacsbugs.donarmstrong.com Resent-Date: Wed, 24 Jun 2009 11:50:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 3208 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Original-Received: via spool by 3208-submit@emacsbugs.donarmstrong.com id=B3208.124584394310116 (code B ref 3208); Wed, 24 Jun 2009 11:50:04 +0000 Original-Received: (at 3208) by emacsbugs.donarmstrong.com; 24 Jun 2009 11:45:43 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n5OBjbgG009951 for <3208@emacsbugs.donarmstrong.com>; Wed, 24 Jun 2009 04:45:39 -0700 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id n5OBjZoB005806; Wed, 24 Jun 2009 20:45:36 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id n5OBjZgh005883; Wed, 24 Jun 2009 20:45:35 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp1.aist.go.jp with ESMTP id n5OBjZDd002423; Wed, 24 Jun 2009 20:45:35 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1MJQv1-0005pp-2K; Wed, 24 Jun 2009 20:45:35 +0900 In-reply-to: <4A4201EF.7000901@gnu.org> (message from Jason Rumney on Wed, 24 Jun 2009 18:37:35 +0800) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Wed, 24 Jun 2009 07:57:30 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:28946 Archived-At: In article <4A4201EF.7000901@gnu.org>, Jason Rumney writes: > Kenichi Handa wrote: > > Although I still can't reproduce the problem (except for the > > very slowness redisplay), I noticed some inefficiency in > > fontset_font. So, I've installed an improvement in the > > TRUNK. As a result, in the case of inserting many #x2203, > > the redisplay got faster. > The memory full problem is still there. I am surprised you don't see it > if you are seeing the slowness, since if things were working correctly, > only the first character displayed should be slow while the fonts are > searched, subsequent insertion of the same character should reuse the > cached font. Even if Emacs once finds a font for a specific character C, it doesn't directly cache the font for C. Instead, the font is recorded in a font-group that is shared with the other characters (in a fontset). So, each time we display C, we must find a font that can display C within the cached fonts. Of course, this process is, I think, far faster than font-listing and opening, it is not instant especially when the target font is at the end of the font-group. The recipe of the original report inserts a very long line. In that case, when Emacs displays a character at the end of line, Emacs tries to check fonts of all characters in the line. This takes considerable amount of time (in my case 4 seconds before my patch and 2.5 seconds after the patch) even if the font is cached. > Your change seems to have reduced the first time display of etc/HELLO Actually it should reduce the second time display of a specific group of characters. But, as HELLO file contains many different characters belonging to the same group, display of some characters gets faster if a character of the same group is already shown. > from 12 seconds for the uniscribe backend to 10 seconds, vs 2 seconds > for the gdi backend and Emacs 22 (though only uniscribe can display the > complex scripts correctly). Subsequent redisplays are near > instantaneous, so it still seems to be searching for fonts rather than > displaying them that takes the time. Anyway, it is not good to use HELLO file for comparing because Emacs 23 knows more kinds of fonts can display a specific character and thus tries more fonts. So, it takes more time to conclude that you system doesn't have a font for that specific character. --- Kenichi Handa handa@m17n.org