Re: Update 1 on Bytecode Offset tracking

[Stefan Monnier <monnier@iro.umontreal.ca>]

> The second branch saves the offset only before a call. Therefore, the
> traceback on all of the functions other than the current one are
> accurate, but the current one is not accurate if the error happens in
> a byte op.

IIUC this has a negligible performance impact.  The info it provides in
not 100% accurate, but I think it's a "sweet spot": it does provide the
byte-offset info and is cheap enough to be acceptable into `master` with
no real downside.

I'd look at it as a "step" along the way: subsequent steps can be to
make use of that info, or to improve the accuracy of that info.

> The third branch bypasses invoking Ffuncall from within
> exec_byte_code, and instead does essentially the same thing that
> Ffuncall does, right in the Bcall ops.

This would be useful in its own right.
So I suggest you try and get this code into shape for `master` as well.

I expect this will tend to suffer from some amount of code duplication.
Maybe we can avoid it via refactoring, or maybe by "clever" macro
tricks, but if the speedup is important enough, we can probably live
with some amount of duplication.

> All of them print the offset next to function names in the backtrace like this: 
>
>
> Debugger entered--Lisp error: (wrong-type-argument stringp t)
>        string-match(t t nil)
>     13 test-condition-case()
>        load("/home/zach/.repos/bench-compare.el/test/test-debug...")
>     78 byte-recompile-file("/home/zach/.repos/bench-compare.el/test/test-debug..." nil 0 t)
>     35 emacs-lisp-byte-compile-and-load()
>        funcall-interactively(emacs-lisp-byte-compile-and-load)
>        call-interactively(emacs-lisp-byte-compile-and-load record nil)
>    101 command-execute(emacs-lisp-byte-compile-and-load record)

Cool!

> With respect to reporting offsets, using code from edebug we have
> a Lisp-Expression reader that will track source-code locations and
> store the information in a source-map-expression cl-struct.  The code
> in progress is here.

How does the performance of this code compare to that of the "native" `read?
And to put it into perspective, have you looked at the relative
proportion of time spent in `read` during a "typical" byte compilation?

There's no doubt that preserving source code information will slow down
byte-compilation but depending on how slow it gets we may find it's not
"worth it".

> Information currently saved is: 
>
> * The expression itself
> * The exact string that was read
> * Begin and end point​s of the sexp in the buffer
> * source-map-expression children (for conses and vectors)

Sounds like a lot of information, which in turn implies a potentially
high overhead (e.g. the "exact string" sounds like it might cost O(N²)
in corner cases, yet provides redundant info that can be recovered from
begin+end points).  Note also that while `read` returns a sexp made
exclusively of data coming from a particular buffer, the code after
macro-expansion can include chunks coming from other buffers, so if we
want to keep the same representation of "sexp with extra info" in both
cases, we can't just assume "the buffer".


        Stefan