> Performance compared to what?
Compared before the patch. The comparison that I mentioned is before and after the PR with the PEP implementation.
> 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.
> 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.
Cheers,
Pablo
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