Hi, On Fri 31 Jul 2009 01:54, Ken Raeburn <raeb...@raeburn.org> 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/
