Re: Elisp performance

[Andy Wingo]

Hello!

(Was away for the weekend, but back hacking all week now.)

On Thu 30 Jul 2009 22:18, Neil Jerram <address@hidden> writes:

> Daniel Kraft <address@hidden> writes:
>
>> Lambda arguments are still always dynamically bound, which is quite a
>> pity as it inhibits tail-call optimization;

Indeed, a pity. Though self-tail calls can be optimized... still,
irritating.

> This prompted me to wonder if using fluids is the best way to
> implement dynamic binding.
>
> Perhaps I'm forgetting something basic, but surely it's using
> `dynamic-wind' that gives us dynamic binding semantics, not fluids.

I haven't read the rest of this thread yet, but this does not seem to be
related to TCO. The middle thunk of a dynamic-wind is *not* called in a
tail context, as indeed it does have a continuation -- the exit thunk.

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

True. Of course, it would be a nice thing to give to elisp -- I mean,
currently in Emacs variables have one value per thread as well, it's
just that there's only one thread. So if we give Emacs the capability to
run multiple threads (as we should IMO), we should provide thread-local
values.

>> My conjecture is that the remaining bottle-neck are the primitive
>> calls, as they are still resolved using the dynamic-binding and fluid
>> mechanisms; so maybe it is really a good idea to change function
>> bindings to just global ones without dynamic scoping, and implement
>> flet/flet* with dynamic-wind.  In contrast to variables, for functions
>> access performance is a lot more important than let performance, I
>> guess, so this might be the way to go.  What do you think?
>
> 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.

Yes, dynamic-wind does involve a cons. I wish this weren't the case, and
perhaps in the future we can fix this, but that's the way it is now.

But regarding speed: profiling is your friend.

http://article.gmane.org/gmane.lisp.guile.devel/6639, for example.

Cheers,

Andy
-- 
http://wingolog.org/