On Wed 15 Jul 2009 10:36, Daniel Kraft <d...@domob.eu> writes:
> Ludovic Courtès wrote:
>>> as well as found a (hopefully good) solution to automatically create
>>> fluids not yet present on reference.
>>
>> Is each Elisp variable mapped to a fluid? Eventually, you may need VM
>> instructions for fluid-{ref,set!}, to speed things up.
>
> Yes it is; and I agree that variable references surely have terrible
> performance at the moment, because of other things that have to go on
> for each reference:
>
> * see if there's a fluid with that name; create if not (but creation is
> only done once of course, so the performance hit is from the check only)
>
> * reference the fluid to get the current value
>
> * check if the value is the special elisp void, in which case an error
> is reported
>
> So taking this all together, I think there's a lot of potential for
> optimization here! Unfortunatly I think that all this is necessary to
> ensure the semantics, but two ideas:
>
> 1) As you suggested, try doing some parts of this with new VM
> operations. Like all of these in one op, or maybe just a "reference and
> error on void" as one op, and/or "lookup the variable in some module,
> and create it if not there" as another. I think we need some planning
> to get the right choice, but it certainly is an important thing for
> performance. But for now I'd suggest to keep on with the current
> implementation and later see what the real performance bottle-neck is
> when running real-world code.
So, agreed wrt perspective on when to optimize. I still think that we
should be able to cache fluid locations in the same way that Scheme
caches variable locations, and add dynamic-ref / dynamic-set analogs to
toplevel-ref / toplevel-set. See their implementations for details on
what I mean.
> 2) I already mentioned some ideas like that before, but if we do careful
> analysis of the elisp code, we can probably get rid of some
> fluid-references; for instance:
>
> (let ((a 5))
> (setq a 1)
> (while ... something which references a a lot)
> (foobar 1 2 3))
I wouldn't bother, to be honest. dynamic-ref will be plenty fast, and a
has to be on the heap anyway, unless the compiler does a lot more
analysis than it currently does.
> I think, however, that this can get fairly complicated and need a lot of
> tweeking in order to get a sensible optimization. So for now I think we
> should try getting the real bottle-necks into VM opterations and see
> what that can buy.
Yes :)
Peace,
Andy
--
http://wingolog.org/
