[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Update 1 on Bytecode Offset tracking
From: |
Stefan Monnier |
Subject: |
Re: Update 1 on Bytecode Offset tracking |
Date: |
Fri, 17 Jul 2020 12:20:06 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> 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
- Update 1 on Bytecode Offset tracking, Zach Shaftel, 2020/07/15
- Re: Update 1 on Bytecode Offset tracking, Stefan Monnier, 2020/07/15
- Re: Update 1 on Bytecode Offset tracking, Zach Shaftel, 2020/07/16
- Re: Update 1 on Bytecode Offset tracking, Eli Zaretskii, 2020/07/16
- Re: Update 1 on Bytecode Offset tracking,
Stefan Monnier <=
- Re: Update 1 on Bytecode Offset tracking, Zach Shaftel, 2020/07/17
- Re: Update 1 on Bytecode Offset tracking, Stefan Monnier, 2020/07/17
- Re: Update 1 on Bytecode Offset tracking, Zach Shaftel, 2020/07/18
- Re: Update 1 on Bytecode Offset tracking, Stefan Monnier, 2020/07/18
- Re: Update 1 on Bytecode Offset tracking, Zach Shaftel, 2020/07/20
- Re: Update 1 on Bytecode Offset tracking, Stefan Monnier, 2020/07/20
Re: Update 1 on Bytecode Offset tracking, Andrea Corallo, 2020/07/16
Update 2 on Bytecode Offset tracking, Zach Shaftel, 2020/07/28