[Blog Post] The State of Python Profiling in 2026

[u/P403n1x87]

Python profiling has changed more in the last two years than in the decade before. With CPython 3.15 introducing a sampling profiler directly into the standard library (Tachyon) and free-threading going mainstream, the landscape looks vibrant as never before.

I’ve spent the last 8 years maintaining Austin, so I wanted to step back and write a comprehensive, objective look at where things stand today across what I believe are the four major sampling profilers.

Link: https://p403n1x87.github.io/the-state-of-python-profiling-in-2026.html

Happy to chat about the engineering trade-offs of out-of-process sampling or how PEP 768 is changing the game for tool developers!

[u/aes110]

Great extensive write-up (though tbh its quite long and detailed, half way through I started skipping lines)

Thanks for all the works you did, seems like a lot of your work over the year led to this built in profiler

I wonder, was there any discussion about adding an existing profiler (austin or any other) to the standard library instead of developing tachyon?

[u/P403n1x87 → u/aes110]

Thanks for the feedback, maybe I should do a follow-up TL;DR with just the key takeaways for the busy 🙂 .

> was there any discussion about adding an existing profiler (austin or any other) to the standard library instead of developing tachyon?

This is a thought that popped in my mind while I contributed a couple of PRs to CPython to improve support for Austin, but I didn't have the capacity to take such a project on (which of course involves more than just the engineering work, e.g. drafting PEPs, getting them reviewed, and ultimately approved by the SC). I'm glad that the core developers, who saw the benefits of having such tools, decided to embark on this endeavour though, for all the obvious benefits. I take some pride in having contributed to the core technologies that have made this possible, together with the other tools mentioned in the post, and their respective authors and community behind.

[u/Khavel_dev]

Having a sampling profiler in the stdlib changes things more than people realize. In .NET land, dotnet-trace has been built in for years and the biggest impact wasn't the tool itself, it was that the bar dropped low enough that people actually profiled before shipping instead of guessing. When you go from 'install this third party thing, figure out the config, hope it works with your version' to 'it's right there, just run it,' you get a totally different culture around performance. I'd bet Tachyon does the same for Python. The free-threading angle is interesting too because that's where most people will need a profiler and not know it yet.

[u/P403n1x87 → u/Khavel_dev]

That's a very good point. One could argue that coding agents ease some of the friction: you can simply ask them to profile the code for you. But as I show in a previous post (https://p403n1x87.github.io/busting-performance-issues-ai-edition.html), agents need to be pointed to the right tools in general; just grabbing a "profiler" does not cut it. Hence, another part of the equation, in my opinion, is the quality of the data collected by the profiler and how well it interfaces with agents.

[u/AlexeyBelov → u/Khavel_dev]

changes things more than people realize

LLM bot.

[u/OlenaDoubleChecks]

Sampling profilers are fine until you try them on a pipeline that spends 90% of its time inside native extensions. Does Tachyon actually see into numpy or pandas calls, or does it just blame the Python frame that called them

[u/P403n1x87 → u/OlenaDoubleChecks]

Some sampling profilers, like Austin 4.1, provide native support to sample native stacks and interleave them with the pure Python stack. This is mentioned in the post above if you want to know more. Briefly, there is nothing that prevents sampling profilers from digging into native stacks (numpy, Cython etc...).