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: profiling emacs-23.1 vs emacs-22.3 Date: Wed, 26 Aug 2009 15:01:49 +0900 Message-ID: References: <200908032029.n73KTi9h017528@godzilla.ics.uci.edu> <200908240807.n7O87ubg024643@godzilla.ics.uci.edu> <200908241826.n7OIQRhS001092@godzilla.ics.uci.edu> <200908251847.n7PIlb4C012720@godzilla.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1251266560 19324 80.91.229.12 (26 Aug 2009 06:02:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2009 06:02:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 26 08:02:33 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 1MgBab-0007Wj-9T for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 08:02:33 +0200 Original-Received: from localhost ([127.0.0.1]:39834 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgBaa-0000Bu-Nt for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 02:02:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgBa4-00008G-VL for emacs-devel@gnu.org; Wed, 26 Aug 2009 02:02:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgBa0-00007t-6f for emacs-devel@gnu.org; Wed, 26 Aug 2009 02:02:00 -0400 Original-Received: from [199.232.76.173] (port=34737 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgBZz-00007o-R9 for emacs-devel@gnu.org; Wed, 26 Aug 2009 02:01:55 -0400 Original-Received: from mx1.aist.go.jp ([150.29.246.133]:50018) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgBZz-0003UR-1I for emacs-devel@gnu.org; Wed, 26 Aug 2009 02:01:55 -0400 Original-Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id n7Q61nFq009881; Wed, 26 Aug 2009 15:01:49 +0900 (JST) env-from (handa@m17n.org) Original-Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id n7Q61ngO018453; Wed, 26 Aug 2009 15:01:49 +0900 (JST) env-from (handa@m17n.org) Original-Received: by smtp3.aist.go.jp with ESMTP id n7Q61nw0021678; Wed, 26 Aug 2009 15:01:49 +0900 (JST) env-from (handa@m17n.org) Original-Received: from handa by etlken with local (Exim 4.69) (envelope-from ) id 1MgBZt-0006U4-9O; Wed, 26 Aug 2009 15:01:49 +0900 In-reply-to: <200908251847.n7PIlb4C012720@godzilla.ics.uci.edu> (message from Dan Nicolaescu on Tue, 25 Aug 2009 11:47:37 -0700 (PDT)) 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:114605 Archived-At: In article <200908251847.n7PIlb4C012720@godzilla.ics.uci.edu>, Dan Nicolaescu writes: > the -nw -Q session has fewer charsets loaded, the -Q version loads the > charset for BIG5 (and others) at startup even though it's running in a > LANG=C environment. Some CJK charsets are necessary to create the default fontset. I think it's possible to avoid loading unnecessary charsets for creating the default fontset. I'll work on it. But, I think the main sloness of -Q version is fontsets. A fontset is a char-table whose elements are vectors, and thus the just-installed optimization doesn't work. By the way, I did this test with (1) Emacs-22, (2) trunk (without gc optimization), and (3) trunk (with gc optimization). % time LANG=C emacs -Q -batch --eval '(dotimes (i 100) (garbage-collect))' The result is: (1) user 0m1.460s (2) user 0m1.772s (3) user 0m1.644s So, (3) is still 13% slower than (1), but I think it's a necessary cost for having the full Unicode support. And usually the slowness of GC doesn't direclty affect the total execution time. > It seems that the charset data structure is too GC intensive, maybe it's > time to rethink it to make it less so. For charset data, I agree that it doesn't have to be a char-table (for encoding) nor a vector (for decoding). I'll consider replacing them with some C structure. --- Kenichi Handa handa@m17n.org