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, <mark@hotpy.org <mailto:mark@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