This is not much of a gain for the CTracer, but for PyTracer.

With this patchtox -e py37-coverage -- testing/test_asser* in pytest's repo takes 50.5s, without it 116.7s (usingtimid = 1 to use the PyTracer).

CTracer: 20.5s without this patch, 20.0s with it (but just run once, it is likely due to a function call being less of an overhead in C).

This appears to be py37+ only.

And pdb/bdb would need to be fixed to set it to True explicitly (https://bugs.python.org/issue36494).

Added to cpython inpython/cpython@5a85167 (bpo-31344).

There alsof_trace_opcodes was added (which must be enabled explicitly).

Codecov Report

Merging#791 intomaster willdecrease coverage by0.01%.
The diff coverage is33.33%.

@@            Coverage Diff             @@##           master     #791      +/-   ##==========================================- Coverage   90.24%   90.22%   -0.02%==========================================  Files          78       78                Lines       10884    10887       +3       Branches     1127     1128       +1     ==========================================+ Hits         9822     9823       +1- Misses        939      941       +2  Partials      123      123

Continue to review full report at Codecov.

Legend -Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered byCodecov. Last update820b255...6682675. Read thecomment docs.

We should be returning None for the trace function if we don't want to trace the frame, and that should be enough. But I don't see where we're returning None. Or is this the decade-old bug?

Yep, it is:https://bugs.python.org/issue11992sigh

I've tried returning None also before, but stopped when noticing that several tests were failing due to it, and assumed coverage.py needs to trace everything still internally. (I've also tried (quickly) to not add todata_stack etc, to match the behavior of "return" not being called anymore).

pypy2 failure (https://travis-ci.com/nedbat/coveragepy/jobs/189126179) might be unrelated?!

I tried restarting the pypy2 failure:https://travis-ci.com/nedbat/coveragepy/jobs/189126179 (oops, same URL...)

The bug about pdb: it affects people trying to stop in the debugger when using coverage? I guess that could happen if you are running a test suite, and want to break on failures?

The problem/bug with pdb is "just" that coverage.py relies on its trace function being called, which is not the case anymore afterpbd.set_trace, yes.
It affects coverage when a debugger is used during test runs interactively, but is also an issue when you're testing with pdb itself (as withpdb++).

@blueyed Are you saying we shouldn't merge this until pdb is changed? Or just that they will want to eventually change?

The discussion above is not related to this PR really, which should just improve performance. I was replying to the "bug about pdb" - which is more a conceptual problem due to only having a single trace function only. pdb could restore any previous one (i.e. coverage.py's), instead of setting it toNone in the end.

Oh, sorry - I forgot about#791 (comment) /python/cpython#12640.
Yes, it should not get merged yet.

I haven't dug super deep into this PR, but maybe it's easier to restart this now that coverage only supports 3.7 upwards?

This same change was made in#1381