[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs Lisp, macros
Re: Emacs Lisp, macros
Fri, 24 Jul 2009 09:00:26 +0200
Thunderbird 220.127.116.11 (X11/20070425)
Andy Wingo wrote:
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.
You mean, (dynamic-ref fluid) equvialent to (fluid-ref fluid) but just
VM optimized, and the same for dynamic-set!? Sounds nice!
Well, just some notes about variable references and performance; there
are still those three things that have to be done I mentioned already
some time before (for setting a variable, 1) and 2) will be relevant):
1) Make sure the fluid itself is there for each variable needed and
create a new one if not.
I did this once on every access, but now I'm scanning each compiled
expression for variable references and ensure all fluids for them
beforehand, so that this is only done once per compiled expression and
not, say, on each iteration in a loop. This brought runtime for one
test down from 2.8s to 0.1s... This pretty amazed me, and I think the
current solution is quite ok.
2) Reference the fluid.
This is what we could do with VM operations, but I've not yet done tests
to find out how much time this really costs compared to 3).
3) Check if value is void and error if it is.
Maybe we could also do this in a VM operation (and then it would
probably cost nearly nothing at all?), but I think that maybe just
optionally getting rid of this test at all (see my remark about compiler
options) is the better solution.
When I've implemented the options to disable 2) and/or 3), I'll do some
timings and let you know about that. Then we can decide if VM ops for
the fluids are worth it and how much we can gain by them.
To go: Hea-Kni-Mon-Pri