Re: Elisp performance

[Ken Raeburn <raeburn@raeburn.org>]

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.

On the other hand, if we want users to be able to write code snippets  
in Elisp and have them callable from a concurrently-multithreaded  
Scheme program (no Emacs processes in sight), I think we'll want the  
multithreaded support for the basic Elisp language sooner rather than  
later, even if multithreaded Emacs needs much more work.

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?

> 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.

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.

Ken