Re: Update 1 on Bytecode Offset tracking

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

> Great! I just followed up on my copyright assignment as I still haven't
> finished that process. I don't know whether this could be exempt or if
> Rocky's assignment is sufficient, but hopefully I will hear back from
> copyright-clerk soon.

While waiting for the paperwork to go through, you can prepare the patch
and we can start discussing it.

> That seems to be the case.  I'll keep looking to see if there's any low
> hanging fruit in terms of splitting up the funcall logic without slowing
> things down.  More testing is necessary, but if a moderate chunk of
> duplicated code is acceptable then there may not be as much work needed
> on that branch as I had thought.

It's a tradeoff, so it's hard to say what is acceptable without seeing
the actual path along with the corresponding measurements of the
performance impact.

> Rough tests indicate it's about three times slower.

Wow!  That's a lot less than I expected.  That makes it quite usable.
This said, we'll probably still want to merge the feature into the
C code simply to avoid the duplication (I expect that the Edebug reader
has never been 100% faithful and that it has probably diverged over
time).

> Removing the string did improve performance, but not by as much as I
> expected. The function that constructs the tree of "children" may be
> slower than it needs to be, so I'll look into improving that. It may not
> be necessary to create the children for vectors since they're constants
> (outside of backquote, at least).

I think vectors are rare enough that the performance benefit of special
casing them is not worth the downside of losing source-location info
when it'd be beneficial.

> Yes, and it won't be easy to maintain the read locations across
> macroexpansion, byte-opt and cconv.

For byte-opt and cconv it's mostly a question of labour.

For macros, OTOH, it's really fundamentally hard (or impossible, in
general).  We could/should introduce some new way to define macros which
knows about "source code annotated with locations".
There's a lot of work on Scheme macros we could leverage for that.


        Stefan