[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 14:33:07 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

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


reply via email to

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