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

[Dmitry Antipov <dmantipov@yandex.ru>]

On 09/05/2014 07:35 PM, Stefan Monnier wrote:

> I'd expect that such escaping would only occur in "unusual setups", as
> a result of later unrelated changes.  E.g. an alloca_string object is
> passed to DECODE_FILE or to Fexpand_file_name, which will usually stay
> within C code or even if it escapes to Elisp its lifetime will not
> escape the stack discipline.
>
> And some times later we get random crashes in odd situations because
> someone figure a clever way to do god-knows-what (e.g. speed things up
> via a memoization) by storing those refs into some global table.

Surely such an errors are possible.  But if we use alloca in general,
there is always a possibility for someone to misuse pointer returned
from it, no matter whether that pointer is used for Lisp_Objects or not.
Any developer good enough in C should be able to find, track and fix
this class of errors, so I don't see a problem here.

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

In somewhat corner cases where an allocation speed is really important,
we can get a very good story.  For example, using build_local_vector
instead of Fmake_vector in Ffind_charset_region makes this function ~18x
times faster (for reatively large buffers):

(defun test-charset ()
   (interactive)
   (let ((start (float-time))
	(max (1- (buffer-size))))
     (dotimes (i max) (find-charset-region (1+ max) (+ max 2)))
     (message "%fs elapsed" (- (float-time) start))))

Of course, no one should detect charsets by scanning buffer in such a way,
but I found this example very illustrative. And I believe that no one can
design an example where using alloca introduces a 18x slowdown :-).

Dmitry