Re: Elisp performance

[Andy Wingo]

Hi,

On Fri 31 Jul 2009 01:54, Ken Raeburn <address@hidden> writes:

> On Jul 30, 2009, at 16:18, Neil Jerram wrote:
>> The main thing I believe that makes a fluid different from a normal
>> variable is that a fluid can have a different value in each thread -
>> which is not relevant to Elisp.
>
> Not yet, at least.
>
> And maybe that's enough.  There's other stuff in Emacs besides variable
> bindings that would require dynamic-wind support, like flet,
> save-excursion (preserves current buffer and position), with-output-to- 
> string and with-output-to-temp-buffer (preserve 'standard-output'), as
> well as any number of explicit calls to unwind-protect from Elisp code
> to alter and restore other global state of the program (e.g., with set- 
> default-file-modes or set-standard-case-table).  The current incarnation
> of these things assumes a single-threaded execution  model.  So, since
> we can't make Emacs multithreaded by simply dropping  Guile Elisp into
> it, if Emacs is all we're concerned about, maybe  assuming
> single-threaded execution only is okay for now.

I think this would be a shame.

Some of the procedures you mention don't necessarily need
dynamic-wind -- they would be sufficiently modelled by a non-reentrant
`with-throw-handler' or such. Downward-only continuations, that is.

> I also don't know how complicated a switch to stop using fluids would
> be.  If it's not too painful, the performance impact would be
> interesting to see -- does it get us closer to the performance of  Emacs
> itself?

I don't think fluids are the issue TBH. I'll see if I can do some
profiling later today.

>> See above.  I'm not sure why fluid access should be significantly
>> slower than non-fluid access, so I would guess that the performance
>> cost is coming from the dynamic-wind part.
>
> For a program the size of Emacs, I'd be concerned about the numbers of
> fluids and dynamic states created, especially since the space cost  (and
> run time cost for growing the vectors, every 20th new entry)  grows with
> the product of the two.  The number of dynamic states may  shrink, but
> the size of each dynamic state -- the number of allocated  fluid slots
> -- doesn't shrink, it only grows.

OTOH, this is the same problem as interning symbols, which Emacs must
surely share -- does Emacs GC its symbols? I wouldn't worry about this
either. Emacs can call some pre-allocation function to pre-grow the
vector at startup.

> While they don't really correlate to anything in Guile Elisp directly,
> the default max_specpdl_size (the specpdl stack is where things are
> tracked for unwinding -- previous bindings, unwind-protect calls,
> previous location data for save-excursion, etc) was raised to 1000 a
> few years ago, and the maximum lisp evaluation depth (limits calls to
> eval, funcall, apply) to 400 just a couple years ago.  I assume that's
> because the previous limits (650 and 300 respectively) were
> occasionally getting reached.  That suggests to me rather a lot of
> dynamic states, and probably a large number of fluids.

Interesting data, thanks.

Cheers,

Andy
-- 
http://wingolog.org/