gh-140358: Bring back elapsed time and unreachable count to gc debug output

[pgdr]

Fixes#140358

This code includes pycore_time.h in gc.c and times the run of _PyGC_Collect. If _PyGC_DEBUG_STATS, then we print the total time used:

E.g.

gc: done, 0 unreachable, 0 uncollectable, 0.0741s elapsed

See also discussion at elapsed time debugging in gc.c at discuss.

• Issue: Bring back elapsed time debugging in gc.c #140358

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[sergey-miryanov]

Please add test to test_gc.py. You have to check that a line with your changes presented in the output.

[pgdr]

I'm not sure if it is appropriate to use the performance counter or the monotonic (raw).

I currently chose monotonic raw, whereas the Python 3.13 version has performance counter.

[sergey-miryanov]

I'm not sure if it is appropriate to use the performance counter or the monotonic (raw).

I currently chose monotonic raw, whereas the Python 3.13 version has performance counter.

IMHO it is better to use counter like in 3.13 vesion.

[pgdr]

@sergey-miryanov Thanks a lot for all the comments. I believe all issues you pointed to are addressed now. A test has been added, and I included the checking of the other lines in the test as well.

I also moved to using performance counter.

[sergey-miryanov]

You need to use the requires_gil_enabled decorator to avoid tests run on the free-threading build.

[pgdr]

@efimov-mikhail I believe I have addressed all your comments, but I still have a doubt regarding including pycore_time. Is it correct as it is now without the include?

[efimov-mikhail]

@efimov-mikhail I believe I have addressed all your comments, but I still have a doubt regarding including pycore_time. Is it correct as it is now without the include?

I think so. CI is green for this PR. And we don't include this file in Python/gc.c on 3.13.
So, I don't see any reason to include this file.

And PyTime_t is defined here:

cpython/Include/cpython/pytime.h

Line 10 in 237dca5

typedefint64_tPyTime_t;

It's part of the public Python C API, as well as PyTime_PerfCounterRaw and PyTime_AsSecondsDouble.

[efimov-mikhail]

LGTM. Thanks for the PR!

But we have to wait for some Core Developers.

[nascheme]

This looks okay to me.

[pablogsal]

This should be probably backported. @nascheme WDYT?

[sergey-miryanov]

@pablogsal@nascheme Thanks!

[pgdr]

This should be probably backported. @nascheme WDYT?

I would be very happy if this found its way to 3.14 as it would help me debugging my main issue #139951.

[efimov-mikhail]

IMO, we can consider this a bug, since removing elapsed line wasn't intended.
I'll add 3.14 label, because we can simply close the backport PR if we decided to.

@pablogsal@nascheme
I hope that's appropriate.

[miss-islington-app]

Thanks @pgdr for the PR, and @pablogsal for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

[miss-islington-app]

Sorry, @pgdr and @pablogsal, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker b2f9fb9db29296410f76009ac65cf81afa8a92a9 3.13

[miss-islington-app]

Thanks @pgdr for the PR, and @pablogsal for merging it 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-140405 is a backport of this pull request to the 3.14 branch.

[efimov-mikhail]

Sorry, some misclicks.

[nascheme]

FWIW, I think backporting is a good idea. It's a small change and it only affects people who turn this option on. Thanks for fixing this.