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: reducing equality tests in displaying text Date: Thu, 29 Jan 2009 09:37:19 +0900 Message-ID: References: NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1233189451 12253 80.91.229.12 (29 Jan 2009 00:37:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2009 00:37:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 29 01:38:44 2009 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 1LSKva-0000f0-GQ for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2009 01:38:42 +0100 Original-Received: from localhost ([127.0.0.1]:59395 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSKuH-0006nP-LM for ged-emacs-devel@m.gmane.org; Wed, 28 Jan 2009 19:37:21 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSKuC-0006l3-56 for emacs-devel@gnu.org; Wed, 28 Jan 2009 19:37:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSKuB-0006j6-EA for emacs-devel@gnu.org; Wed, 28 Jan 2009 19:37:15 -0500 Original-Received: from [199.232.76.173] (port=54553 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSKuB-0006ii-43 for emacs-devel@gnu.org; Wed, 28 Jan 2009 19:37:15 -0500 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:55834) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LSKuA-0001sM-Cn for emacs-devel@gnu.org; Wed, 28 Jan 2009 19:37:14 -0500 Original-Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id n0T0bALO019219; Thu, 29 Jan 2009 09:37:10 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id n0T0bAiF020401; Thu, 29 Jan 2009 09:37:10 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp4.aist.go.jp with ESMTP id n0T0b9FB004718; Thu, 29 Jan 2009 09:37:09 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1LSKuF-0005FF-G7; Thu, 29 Jan 2009 09:37:19 +0900 In-reply-to: (message from YAMAMOTO Mitsuharu on Wed, 28 Jan 2009 18:11:31 +0900) X-detected-operating-system: by monty-python.gnu.org: Solaris 9 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:108341 Archived-At: In article , YAMAMOTO Mitsuharu writes: > > Are you sure that those calls mostly return nil? Could you > > please check if this patch surely improve the performance? > Here is the result. > 750.9 ms emacs mark_object > 153.4 ms libfreetype.6.dylib tt_cmap4_char_map_binary > 126.7 ms emacs Fgarbage_collect > 106.8 ms emacs mark_vectorlike > 64.8 ms emacs x_produce_glyphs > 61.5 ms emacs char_table_ref > 47.5 ms emacs fontset_find_font > 33.3 ms emacs get_next_display_element > 30.3 ms emacs face_for_char > 29.3 ms libXft.2.dylib XftGlyphExtents > 29.3 ms emacs assq_no_quit > 29.3 ms emacs find_interval > 27.3 ms emacs hash_lookup > 26.3 ms emacs make_uninit_multibyte_string > 25.2 ms emacs sub_char_table_ref Ummm, this result is surprising, but I found a bug in fontset_get_font_group that is the culprit of so many calls of char_table_ref_and_range. I simply forgot to record the result of previous call in the case of nil. I should have noticed it when you wrote that from and to were never used in such a case. :-( Anyway, please try the new code. I think that the calls of char_rable_ref itself is reduced. > > Hmmm. I've just found that Xft has the function > > XftCharExists now. I remember that it didn't exist in a > > rather old vesion. Does your Xft library have this > > function? > It exists. But it simply uses the `charset' member in struct _XftFont: > _X_EXPORT FcBool > XftCharExists (Display *dpy, > XftFont *pub, > FcChar32 ucs4) > { > if (pub->charset) > return FcCharSetHasChar (pub->charset, ucs4); > return FcFalse; > } > Is there any reason you prefer an Xft-level routine to > fontconfig-level? By adding some `FcCharSet *' member in struct > ftfont as I said, you don't need to "override" `has_char' function in > the xft driver, and the ftx driver can also benefit from it for free. In ftfont.c, fontconfig is used only to list fonts. The other actual font driving is done directly by freetype. Currently, the exception is ftfont_has_char, but I want to find a way to avoid using fontconfig here too. The reason why I want to keep this separation is that listing fonts and using a font is different tasks, and, in the future, I want to allow different combinations of them. On the other hand, as Xft is so tightly combined with fontconfig, and it already has `charset' member in XftFont structure, it is nonsense not to utilize it. --- Kenichi Handa handa@m17n.org