René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[3.14t] Free-threaded GC performance regression on tuples","articleBody":"# Bug report\n\n### Bug description:\n\nI am observing a significant performance regression in the Python 3.14.2 Free-Threading build compared to the build with GIL when constructing large lists of tuples.\n\nThis seems related to the recent work in issue #139951 and PR #140262. While the Standard 3.14.2 build appears to have resolved the performance regression, the Free-Threading build is still significantly slower in this scenario. I have confirmed that 3.14.0 (regular builld) shows the performance regression, 3.14.2 (regular) seems to have fixed it (thanks to the previous PR) but 3.14.2t (at least the version shipped on uv) still contains the issue.\n\nI also see what is the output of `gc.is_tracked` (see below) for free threaded vs standard, there seems to be a difference but I did not dig into the details so far on how GC works on standard vs free threaded Python, sorry.\n\n### Benchmark Results (N=15,000,000) (r6id.8xlarge AWS instance)\n\n| Build | GC State | Time | `gc.is_tracked` says |\n| :--- | :--- | :--- | :--- |\n| **3.14.0 (Standard)** | Enabled | **142.876s** | `True` |\n| **3.14.0 (Standard)** | Disabled | **1.068s** | `True` |\n| **3.14.0 (Free-Threaded)** | Enabled | **37.074s** | `False` |\n| **3.14.0 (Free-Threaded)** | Disabled | **0.637s** | `False` |\n| **3.14.2 (Standard)** | Enabled | **0.974s** | `True` |\n| **3.14.2 (Standard)** | Disabled | **0.969s** | `True` |\n| **3.14.2 (Free-Threaded)** | Enabled | **36.679s** | `False` |\n| **3.14.2 (Free-Threaded)** | **Disabled** | **0.644s** | `False` |\n\n### Reproduction Script\n\n```python\nimport time\nimport gc\nimport sys\n\ndef benchmark_step(disable_gc):\n    if disable_gc: \n        gc.disable()\n    \n    t0 = time.perf_counter()\n    _ = [(0, 0, i) for i in range(15_000_000)]\n    dt = time.perf_counter() - t0\n    \n    status = \"GC DISABLED\" if disable_gc else \"GC ENABLED \"\n    print(f\"{status}: {dt:.3f}s\")\n    \n    if disable_gc:\n        gc.enable()\n\nif __name__ == \"__main__\":\n    print(f\"Python Version: {sys.version}\")\n    sample = (0, 0, 1)\n    print(f\"Is tuple(int, int, int) tracked? {gc.is_tracked(sample)}\")\n    \n    print(\"--- Benchmark ---\")\n    benchmark_step(disable_gc=False)\n    benchmark_step(disable_gc=True)\n```\n\nIn more detail this is my 3.14.2 regular build:\nPython Version: 3.14.2 (main, Dec  9 2025, 19:03:28) [Clang 21.1.4 ]\n\nAnd my free threaded build:\nPython Version: 3.14.2 free-threading build (main, Dec  9 2025, 19:03:17) [Clang 21.1.4 ]\n\nIt's particularly weird that when disabling GC (despite the tuple being untracked) the regression goes away... Is it possible there is a disconnect between the flag `is_tracked` checks and the actual logic used by the free-threaded collector?\n\ncc @colesbury @nascheme @markshannon \n\n### CPython versions tested on:\n\n3.14\n\n### Operating systems tested on:\n\nLinux\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-142562\n* gh-142617\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/MaxiBoether","@type":"Person","name":"MaxiBoether"},"datePublished":"2025-12-10T19:53:04.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":6},"url":"https://github.com/142531/cpython/issues/142531"}