Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

GH-124715: Move trashcan mechanism intoPy_Dealloc#132280

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
markshannon merged 9 commits intopython:mainfromfaster-cpython:trashcan-in-dealloc
Apr 30, 2025

Conversation

markshannon
Copy link
Member

@markshannonmarkshannon commentedApr 8, 2025
edited by bedevere-appbot
Loading

@nascheme
Copy link
Member

This is a good idea, IMHO. I had a similar PR but Mark's is more elegant than mine.

@markshannonmarkshannon marked this pull request as ready for reviewApril 9, 2025 12:28
@markshannonmarkshannon added the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelApr 9, 2025
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by@markshannon for commit8aa20f2 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F132280%2Fmerge

If you want to schedule another build, you need to add the🔨 test-with-buildbots label again.

@bedevere-botbedevere-bot removed the 🔨 test-with-buildbotsTest PR w/ buildbots; report in status section labelApr 9, 2025
@markshannon
Copy link
MemberAuthor

Initialperformance numbers are a bit down. 0.2% - 1.6% slower.

I'm testing another branch that addsPyThreadState * as a parameter to_PyDealloc, which might reduce the impact.

@markshannon
Copy link
MemberAuthor

With faster recursion checks,performance is mixed but no worse overall:

  • Linux ARM: 0.4% slower
  • Linux x86: 1.5% slower
  • Windows x86: 0.9% faster
  • Mac (ARM): 3.8% faster

Although the 1.5% slowdown on linux x86 is concerning.

I also tried passing in the thread state as a parameter to_Py_Dealloc which is a much larger change.Results were a bit worse than this PR:

  • Linux ARM: no change
  • Linux x86: 1.3% slower
  • Windows x86: 1.3% slower
  • Mac (ARM): 3.9% faster

@iritkatriel
Copy link
Member

Maybe perf will be better with just one additional if for a decref that is not a container. So you have an implementation of decref for containers, and do one if to decide whether to apply it or stay with the current one.

@markshannon
Copy link
MemberAuthor

Maybe perf will be better with just one additional if for a decref that is not a container. So you have an implementation of decref for containers, and do one if to decide whether to apply it or stay with the current one.

Do you mean a test inPy_DECREF or inPy_Dealloc?
We really want to avoid adding more branches toPy_DECREF asPy_DECREF is inlined in so many places.

Adding a branch inPy_Dealloc would save the stack checks, but those are cheap. Getting the "margin" is a load, subtract and shift.

Testing for collections is more expensive.PyObject_IS_GC does three loads, two of which are dependent on the first.

@iritkatriel
Copy link
Member

Maybe perf will be better with just one additional if for a decref that is not a container. So you have an implementation of decref for containers, and do one if to decide whether to apply it or stay with the current one.

Do you mean a test inPy_DECREF or inPy_Dealloc?

Sorry, yeah, dealloc. Maybe not worth it.

Copy link
Member

@vstinnervstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The overall design LGTM.

I added a few comments.

@rhettingerrhettinger removed their request for reviewApril 16, 2025 02:26
@markshannonmarkshannon merged commit44e4c47 intopython:mainApr 30, 2025
48 checks passed
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure⚠️⚠️⚠️

Hi! The buildbots390x RHEL8 3.x (tier-3) has failed when building commit44e4c47.

What do you need to do:

  1. Don't panic.
  2. Checkthe buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/509/builds/9127) and take a look at the build logs.
  4. Check if the failure is related to this commit (44e4c47) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/509/builds/9127

Failed tests:

  • test_functools

Failed subtests:

  • test_async_global_awaited_by - test.test_external_inspection.TestGetStackTrace.test_async_global_awaited_by

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):  File"/home/buildbot/buildarea/3.x.cstratak-rhel8-s390x/build/Lib/test/test_external_inspection.py", line531, intest_async_global_awaited_byself.assertEqual([[['echo_client_spam'],'echo client spam', [[['main'],'Task-1', []]]]], entries[-1][1])~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^AssertionError:Lists differ: [[['echo_client_spam'], 'echo client spam', [[['main'], 'Task-1', []]]]] != []

@vstinner
Copy link
Member

Hi! The buildbot s390x RHEL8 3.x (tier-3) has failed when building commit44e4c47.

test_recursive_pickle (test.test_functools.TestPartialPy.test_recursive_pickle) ...Objects/classobject.c:247: _PyObject_GC_UNTRACK: Assertion "_PyObject_GC_IS_TRACKED(((PyObject*)(op)))" failed: object not tracked by the garbage collectorEnable tracemalloc to get the memory block allocation tracebackobject address  : 0x3ffae27c8f0object refcount : 0object type     : 0x1669768object type name: methodobject repr     : <refcnt 0 at 0x3ffae27c8f0>Fatal Python error: _PyObject_AssertFailed: _PyObject_AssertFailedPython runtime state: initializedCurrent thread 0x000003ffb6177270 [python] (most recent call first):  File "/home/buildbot/buildarea/3.x.cstratak-rhel8-s390x/build/Lib/test/test_functools.py", line 420 in test_recursive_pickle  (...)

vstinner added a commit to vstinner/cpython that referenced this pull requestApr 30, 2025
Replace _PyObject_GC_UNTRACK() with PyObject_GC_UnTrack() to not failif the method was already untracked.
@vstinner
Copy link
Member

I wrote#133199 to fix test_functools.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@naschemenaschemenascheme left review comments

@vstinnervstinnervstinner approved these changes

@iritkatrieliritkatrieliritkatriel approved these changes

@ericsnowcurrentlyericsnowcurrentlyAwaiting requested review from ericsnowcurrentlyericsnowcurrently is a code owner

@methanemethaneAwaiting requested review from methanemethane is a code owner

@1st11st1Awaiting requested review from 1st11st1 is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

5 participants
@markshannon@nascheme@bedevere-bot@iritkatriel@vstinner

[8]ページ先頭

©2009-2025 Movatter.jp