[Top][All Lists]

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

Re: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_S

From: Dmitry Antipov
Subject: Re: Benchmarking temporary Lisp objects [Was: Re: [RFC] temporary Lisp_Strings]
Date: Mon, 08 Sep 2014 16:01:43 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

On 09/08/2014 02:33 PM, Dmitry Antipov wrote:

Basically, this risks making Elisp's semantics more murky, so it has to
come with a good performance story.

Here is a "real-life" example with my favorite benchmark running over xdisp.c:

(defun scroll-up-benchmark ()
  (let ((oldgc gcs-done)
        (oldtime (float-time)))
    (condition-case nil (while t (scroll-up) (redisplay))
      (error (message "GCs: %d Elapsed time: %f seconds"
                      (- gcs-done oldgc) (- (float-time) oldtime))))))

==> 401 GCs, ~29.9s.

With two-lines change:

=== modified file 'src/textprop.c'
--- src/textprop.c      2014-09-07 07:04:01 +0000
+++ src/textprop.c      2014-09-08 11:49:52 +0000
@@ -1319,7 +1319,8 @@
 markers).  If OBJECT is a string, START and END are 0-based indices into it.  
   (Lisp_Object start, Lisp_Object end, Lisp_Object property, Lisp_Object 
value, Lisp_Object object)
-  Fadd_text_properties (start, end, list2 (property, value), object);
+  Lisp_Object val = scoped_cons (property, scoped_cons (value, Qnil));
+  Fadd_text_properties (start, end, val, object);
   return Qnil;

it shows 399 GCs and ~29.6s.

Here we just allocate 2 cons cells (32 bytes on a 64-bit system) on stack,
and can see a measurable performance improvement.  I believe that carefully
used stack allocation can give a much more visible improvement for a wide
range of Lisp workloads.


reply via email to

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