Farid Mirzayev
By day, he works as a Python Software Developer at Ørsted, helping automate simulation workflows for power engineers. By curiosity, he enjoys exploring Python internals, performance tools, and the strange ways developers convince themselves their code is fast before measuring it.
Session
Your Python program is slow, so you run cProfile. It reports exact call counts and instrumented timings, but tracing every function call can change the workload you are trying to understand. Run a sampling profiler on the same program and a different picture emerges. Neither result is inherently wrong: each profiler answers a different question.
In this talk, we will compare cProfile, external sampling tools such as py-spy and austin, and Python 3.15's new standard-library sampling profiler, profiling.sampling, also known as Tachyon.
Using the same mixed workload throughout, we will see why call-heavy code is especially vulnerable to tracing overhead, how periodic stack samples become estimated hotspots, and what sampling can miss. We will then compare Tachyon's wall-clock and CPU modes to reveal an important distinction: time spent waiting can dominate one profile and disappear from the other.
We will also see how Tachyon can profile a script or attach to an existing Python process without modifying or restarting it.
You will leave with a practical framework: use tracing when you need exact call counts, sampling when you need representative hotspots or production diagnostics, and benchmarking when you need to compare small performance differences.