Re: Emacs Lisp, macros

[Daniel Kraft <d@domob.eu>]

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.

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

In order to preserve dynamic scoping for a in the call to foobar, we 
still have to save a in a fluid as well as do the setq on the fluid 
value.  But all references to a within the while-loop (if they are 
reads) are known to refer to the let-bound a, so we could optimize them 
and not take a fluid-ref every now and then.

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.

> There's 1.5 framework.  The first one is under `test-suite/tests', used
> to test the API.  The remaining 0.5 is under `testsuite': it's inherited
> from Guile-VM and is used to make sure interpreted and compiled code
> yield the same result.
> 
> I think the best way would be to add, say,
> `test-suite/tests/elisp-compiler.test' (there's already `elisp.test'),
> and from there use a macro akin to Andy's `c&e' in `bytevectors.test'.

Ok thanks for the hint!  So far I did mainly look into testsuite, but 
then I'll take a look at the framework in test-suite and see if I can do 
something useful there :)

cheers,
Daniel