[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Elisp performance
From: |
Daniel Kraft |
Subject: |
Re: Elisp performance |
Date: |
Fri, 31 Jul 2009 08:09:08 +0200 |
User-agent: |
Thunderbird 2.0.0.0 (X11/20070425) |
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