Hi Pablo,
On 29/10/2020 9:56 am, Pablo Galindo Salgado wrote:
> Performance compared to what?
Compared before the patch. The comparison that I mentioned is before and
after the PR with the PEP implementation.
PEP 626 changes the line number table and the compiler.
Such a comparison would not test the performance impact of the change to
`f_lineno`, as it will likely be swamped by the other changes.
> The current behavior of `f_lineno` is ill-defined, so mimicking it would
be tricky
Maybe I failed to express myself: that's fine, we don't need to mimick
the current behaviour of f_lineno or change anything in the PEP
regarding that. I just want to check that the new semantics do not slow
down anything in a subtle way.
The new semantics may well result in some slowdowns. That's stated in
the PEP.
I don't think I can reliably isolate the effects of the (very slight)
change in the behavior of f_lineno.
> What's the reason for supposing that it will be slower?
There is no real concern, but as there were some conversations about
performance and the pep mentions that "the "f_lineno" attribute of the
code object will be updated to point the current line being executed" I
just want to make sure that updating that field on every bytecode line
change does not affect anything. Again, I am pretty sure it will be
negligible impact and the performance check should be just a routine
confirmation.
When you say updating "field", are you thinking of a C struct?
That's an implementation detail.
The PEP states that the f_lineno *attribute* of the code object will be
updated.
Note that the behavior of 3.9 is weird in some cases:
test.py:
import sys
def print_line():
print(sys._getframe(1).f_lineno)
def test():
print_line()
sys._getframe(0).f_trace = True
print_line()
print_line()
test()
$ python3.9 ~/test/test.py
7
8
8
With PEP 626 this is required to print:
7
9
10
Cheers,
Mark.
Cheers,
Pablo
On Thu, 29 Oct 2020, 09:47 Mark Shannon, <m...@hotpy.org
<mailto:m...@hotpy.org>> wrote:
Hi,
That's great. Thanks Pablo.
On 29/10/2020 1:32 am, Pablo Galindo Salgado wrote:
> On behalf of the steering council, I am happy to announce that as
> BDFL-Delegate I am
> accepting PEP 626 -- Precise line numbers for debugging and other
tools.
> I am confident this PEP will result in a better experience for
> debuggers, profilers and tools
> that rely on tracing functions. All the existing concerns regarding
> out-of-process debuggers
> and profilers have been addressed by Mark in the latest version
of the
> PEP. The acceptance of
> the PEP comes with the following requests:
>
> * The PEP must be updated to explicitly state that the API functions
> described in the
> "Out of process debuggers and profilers" must remain
self-contained
> in any potential
> future modifications or enhancements.
> * The PEP states that the "f_lineno" attribute of the code object
will
> be updated to point to
> the current line being executed even if tracing is off. Also,
there
> were some folks concerned with
> possible performance implications. Although in my view there
is no
> reason to think this will impact
> performance negatively, I would like us to confirm that
indeed this
> is the case before merging the
> implementation (with the pyperformance test suite, for example).
Performance compared to what?
The current behavior of `f_lineno` is ill-defined, so mimicking it
would
be tricky.
What's the reason for supposing that it will be slower?
Cheers,
Mark.
>
> Congratulations Mark Shannon!
>
> Thanks also toeveryone else who provided feedback on this PEP!
>
> Regards from rainy London,
> Pablo Galindo Salgado
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/WHBHMT5DD3AR3PKO6IQ6XDZBWTCWF3O7/
Code of Conduct: http://python.org/psf/codeofconduct/
