[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: please review new branch feature/byte-unwind-protect
From: |
Stefan Monnier |
Subject: |
Re: please review new branch feature/byte-unwind-protect |
Date: |
Tue, 23 Jan 2018 11:37:10 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> It's partly for efficiency -- I didn't benchmark it though.
I'd be interested to see some benchmarks, as well (e.g. comparing
old-unwind-protect vs new-unwind-protect vs prog1, where the prog1 case
is used as the "speed of light" reference).
> Also this seems like an un-finished to-do item from the lexical binding
> conversion.
Not exactly "unfinished", but yes, it's a good change.
> I don't think there's a cost to this change.
There's always costs:
- fewer bytecodes left.
- incompatility of .elc files.
- potentially slower execution (hopefully it's the reverse, but without
measuring it, it's difficult to be sure).
- subtle changes (e.g. the debugger backtrace, or the behavior of
called-interactively-p when called from within the 2nd part of an
unwind-protect).
>From where I stand I think they're worth the trouble, tho it depends on
the benchmarks (I don't have a good intuition for the cost of setjmp,
mostly, so while I think/hope that it will make things faster, I'm not
completely sure).
BTW, when I wrote those FIXME, the implementation strategy I was thinking
of was:
- use byte-codes with a similar semantics to the ones you introduce.
- implement the pushunwindprotect by pushing onto the specpdl stack
an entry that contains a reference to the bytecode stack and
bytecode's pc (note: no setjmp).
- when running the unwind_protect during a non-local exit (i.e. from
unbind_to), run the byte-code interpreter using that saved stack and pc.
Stefan