Re: [PATCH] Unconditional quit on SIGUSR2

[Stefan Monnier]

> Speaking of ... a while back I wrote a patch to make the bytecode
> interpreter be token-threaded.  I was going to commit it, but I thought
> maybe I should wait for lexbind to be merged...?

It might be worth adapting it to the lexbind branch and testing its
performance there (i.e. test its performance impact on lexical-binding
code, such as the bytecomp/byte-opt/macroexp which have all been
converted to use lexical-binding).


        Stefan


As things stand on the lexbind branch, using lexical-binding does not
result in a speed improvement, although it could: basically, with
dynamic scoping a let is turned into:
- eval the inital value of the variable.
- call byte-varbind.
- evaluate the body of the let.
- when you need to read the variable, you call byte-varref.
- when you need to write to the variable, you call byte-varset.
- call byte-unbind.
whereas with lexical scoping a let is turned into:
- eval the inital value of the variable.
- do nothing
- evaluate the body of the let.
- when you need to read the variable, you call byte-stackref.
- when you need to write to the variable, you call byte-stackset.
- call byte-discard.
so we saved one call to byte-varbind and we replaced byte-varrefs by
byte-stackrefs, byte-varsets by byte-stackset, and byte-unbind by
byte-discard.  The replacements are very good because they are simpler
operations that can run faster.  But the overall performance is not
noticeably improved (and can be worsened) because the above benefits are
defeated by the fact that calls to mapcar often need to build a closure,
and worse: unwind-protect, condition-case, and catch need to build
closures as well.
Still, these last three could be improved to not necessitate closures (I
opted to not do that (yet) because it would require more substantial
changes and I want to focus on delivering the lexical semantics first,
and keep the performance for later).
OK, I got a bit lost, but what I intended to get at is that the simpler
byte-codes we now use (stackref/stackset/discard) spend a larger
proportion of their time in interpreter-overhead, so there's a chance
that token-threading will get a bit more benefits on such code that it
does on dynamically scoped code where more operations need to call out
to functions anyway.