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

[Dmitry Antipov]

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 ()
  (interactive)
  (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.

Dmitry