GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Optimise the way tracemalloc and PyRefTracer hooks work · Issue #125790 · python/cpython

Optimise the way tracemalloc and PyRefTracer hooks work #125790

New issue
Copy link
New issue
Copy link
Open
Open
Optimise the way tracemalloc and PyRefTracer hooks work#125790
Copy link
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usagePerformance or resource usagetype-featureA feature request or enhancementA feature request or enhancement

Description

@pablogsal
pablogsal
opened on Oct 21, 2024
Issue body actions

In #125703 @markshannon has raised that he is unhappy about the performance implications of where these hooks are placed and in a call we discussed that he has some ideas on how to make them more performant by moving them elsewhere or adapting then.

I am opening this issue to track and sync about these improvements for 3.14 and beyond.

Reacted by Carol Willing and Erlend E. Aasland

Activity

  1. pablogsal
    added
    performancePerformance or resource usagePerformance or resource usage
    on Oct 21, 2024
  2. markshannon commented on Oct 25, 2024

    @markshannon
    markshannon
    on Oct 25, 2024
    Member
    More actions

    I think we can fix the performance issues by raising the level at which allocation/free goes through a function pointer.

    Instead of a malloc-like interface void *malloc(size_t size), we should be returning partially initialized objects.
    PyObject *obj_malloc(PyTypeObject *tp, size_t size, size_t presize) would allocate a chunk of memory size + presize, returning a PyObject * pointing to that memory + presize, with the ob_type field set to tp and the ob_refcount set to one.

    This is low-enough level to be fully general, but with enough context to support tracemalloc.

    I think we would need the following implementations, switchable at runtime:

    • default
    • tracemalloc
    • custom (used when the underlying PEP 445 allocator is changed)
    • custom-tracemalloc (used when the underlying PEP 445 allocator is changed)
    • freethreading
    • freethreading-tracemalloc

    We don't need (or want) to switch between the free-threading and default allocators, but it keeps the rest of the code simpler if they have the same interface.

  3. markshannon commented on Apr 7, 2025

    @markshannon
    markshannon
    on Apr 7, 2025
    Member
    More actions

    Having played around with this a bit, I'm going with a slightly different design.

    All allocations and deallocations will go through a single (inline) function taking the threadstate as well as the type and sizes.
    This will allocate from per-size freelists, then fall back to the basic malloc/free functions.
    This works as we can disable, or re-enable, the freelists when PyRefTracer_SetTracer or PyMem_SetAllocator are called.

  4. picnixz
    added
    type-featureA feature request or enhancementA feature request or enhancement
    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
    on Apr 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)performancePerformance or resource usagePerformance or resource usagetype-featureA feature request or enhancementA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402520 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.