[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: profiling emacs-23.1 vs emacs-22.3

From: Dan Nicolaescu
Subject: Re: profiling emacs-23.1 vs emacs-22.3
Date: Tue, 25 Aug 2009 23:33:27 -0700 (PDT)

Kenichi Handa <address@hidden> writes:

  > In article <address@hidden>, Dan Nicolaescu <address@hidden> 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);
+  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)
   int cdr_count = 0;
+  call_count_mark_object++;
   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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]