Re: Elisp performance

[Daniel Kraft <d@domob.eu>]

Ken Raeburn wrote:
  > 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.

As already stated upthread, I'm not sure about this myself...  It would 
be cool to stay as flexible as possible with regards to future 
multi-threading, but on the other hand I also like the idea of getting 
rid of the fluids.  My timings there seem to suggest that fluids at 
least have "some" performance hit.

Of course, anyone interested in performance can also use lexical-let 
instead of let and also get rid of all this performance problems as well 
;)  But the same argument may hold for the threading argument, too, so 
if you want to write elisp code that is called from multi-threaded 
Scheme, just avoid dynamic binding and you'll get no problems...

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

Well, it will not be trivial but also quite doable, I think.  Regarding 
the performance, I'm quite sure it will help, but not so much about the 
actual quantitative impact -- but if we're lucky, it might be like that 
between dynamic and lexical let of my timings in the original post. 
This seems quite plausible to me.

Daniel

-- 
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri