From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: profiling emacs-23.1 vs emacs-22.3 Date: Tue, 25 Aug 2009 23:33:27 -0700 (PDT) Message-ID: <200908260633.n7Q6XRXi018187@godzilla.ics.uci.edu> 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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1251268531 23815 80.91.229.12 (26 Aug 2009 06:35:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2009 06:35:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 26 08:35:24 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 1MgC6N-0006Bo-Rw for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 08:35:24 +0200 Original-Received: from localhost ([127.0.0.1]:52022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgC6M-0005Wq-QT for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 02:35:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgC6H-0005Wk-Ro for emacs-devel@gnu.org; Wed, 26 Aug 2009 02:35:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgC6D-0005Tp-35 for emacs-devel@gnu.org; Wed, 26 Aug 2009 02:35:17 -0400 Original-Received: from [199.232.76.173] (port=49944 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgC6C-0005Tk-T8 for emacs-devel@gnu.org; Wed, 26 Aug 2009 02:35:12 -0400 Original-Received: from barrelv2.ics.uci.edu ([128.195.1.114]:39377) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1MgC6C-00085E-9v for emacs-devel@gnu.org; Wed, 26 Aug 2009 02:35:12 -0400 Original-Received: from godzilla.ics.uci.edu (godzilla.ics.uci.edu [128.195.10.101]) by barrelv2.ics.uci.edu (8.13.8+Sun/8.13.8) with ESMTP id n7Q6XStf021933; Tue, 25 Aug 2009 23:33:28 -0700 (PDT) Original-Received: (from dann@localhost) by godzilla.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id n7Q6XRXi018187; Tue, 25 Aug 2009 23:33:27 -0700 (PDT) In-Reply-To: (Kenichi Handa's message of "Wed, 26 Aug 2009 15:01:49 +0900") Original-Lines: 99 X-ICS-MailScanner-Information: Please contact the ISP for more information X-ICS-MailScanner-ID: n7Q6XStf021933 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@godzilla.ics.uci.edu X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) 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:114606 Archived-At: Kenichi Handa writes: > 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. Can the data in the default fontset be in the dumped image in pure memory? To not have to create it every time on start up and GC it should be a win. > 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 does, see the profiling data that I sent. The problem with GC is that it will flush all the caches if there's too much memory to walk over. And the slowdown in GC speed is directly related to the big increase in the number of GCable objects. If you want to see a bit of this, please try this simple instrumentation (is should apply to both 22.3 and CVS trunk): Index: alloc.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/alloc.c,v retrieving revision 1.449 diff -u -3 -p -u -p -r1.449 alloc.c --- alloc.c 25 Aug 2009 06:03:09 -0000 1.449 +++ alloc.c 26 Aug 2009 06:28:36 -0000 @@ -4963,6 +4963,7 @@ inhibit_garbage_collection () return count; } +int call_count_mark_object = 0; DEFUN ("garbage-collect", Fgarbage_collect, Sgarbage_collect, 0, 0, "", doc: /* Reclaim storage for Lisp objects no longer needed. @@ -4986,6 +4987,9 @@ returns nil, because real GC can't be do Lisp_Object total[8]; int count = SPECPDL_INDEX (); EMACS_TIME t1, t2, t3; + int bef = call_count_mark_object; + + /* fprintf (stderr, "bef gc mark_object count = %d\n", call_count_mark_object); */ if (abort_on_gc) abort (); @@ -5278,6 +5282,8 @@ returns nil, because real GC can't be do EMACS_USECS (t3) * 1.0e-6); gcs_done++; + fprintf (stderr, "after gc mark_object delta = %d\n", call_count_mark_object - bef); + return Flist (sizeof total / sizeof *total, total); } @@ -5410,6 +5416,8 @@ mark_object (arg) #endif int cdr_count = 0; + call_count_mark_object++; + loop: if (PURE_POINTER_P (XPNTR (obj))) > > 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. Great, thanks!