> 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 On Thu, 29 Oct 2020, 09:47 Mark Shannon, <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/BIUZGR4YSCTV5FFNSN2RSCGB6MC3U2RB/ Code of Conduct: http://python.org/psf/codeofconduct/
