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

[Dmitry Antipov <dmantipov@yandex.ru>]

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