Sampling estimates hot spots by periodic observations and normally imposes less target-process overhead; deterministic tracing records every Python call with exact counts at greater cost.
Understanding the Concept
Sampling estimates hot spots by periodic observations and normally imposes less target-process overhead; deterministic tracing records every Python call with exact counts at greater cost. Neither replaces a controlled benchmark.
Profiling itself can distort timings; benchmark with instrumentation disabled when comparing speed.
How to interpret the measurement
Before optimizing, establish an objective measurement and a representative workload. Memory size, function-call counts, elapsed time and samples are different metrics: knowing one does not determine the others. Repeat observations before drawing a conclusion about a performance regression.
Profiling output is evidence for finding a bottleneck, not a performance guarantee. Check that the program still produces the correct result after any optimization and note version, input size and measurement conditions.
Worked Example
Read the code from the first line to the last. Identify which values are inputs, which operation is being demonstrated and what should happen before running it.
import cProfile
from time import perf_counter
def calculate():
return sum(i*i for i in range(2000))
start = perf_counter()
calculate()
print("Elapsed seconds:", perf_counter() - start)
profiler = cProfile.Profile()
profiler.runcall(calculate)
print("Call-level profile captured")
Walkthrough: What Each Part Does
- The imports make cProfile, time available. These are standard-library building blocks unless the example explicitly names an external tool.
- The definition calculate creates reusable behavior. Its body runs when called, awaited or instantiated; defining it alone does not run the body of an ordinary function.
- The printed number or profile is diagnostic data. Repeat the observation and identify the unit before comparing values.
This demonstration focuses on one practical behavior. Before changing several lines, vary one input or one configuration choice and check whether the result changes for the reason you expected.
The example uses terminal, platform, external tool or process behavior that was not exercised automatically. Run it only in a suitable environment after reviewing the shown permissions and paths.
Important Behavior and Edge Cases
Claiming that one profiler is always more accurate regardless of whether the question concerns calls, time, waiting or sampling variance.
Profiling itself can distort timings; benchmark with instrumentation disabled when comparing speed.
Practice Exercise
Select profiling.sampling for a long-running server and profiling.tracing for exact call counts in a short helper.
Write down the result you expect before running your changed code. Check at least one normal case and one boundary or failure case. If your example starts workers or opens resources, verify how they are cleaned up.
Further reading: official documentation and API reference.
Common Beginner Mistakes
- Claiming that one profiler is always more accurate regardless of whether the question concerns calls, time, waiting or sampling variance.
- Comparing results from different workloads or environments as if the measurements were directly interchangeable.
Key Takeaways
- Sampling estimates hot spots by periodic observations and normally imposes less target-process overhead; deterministic tracing records every Python call with exact counts at greater cost.
- Profiling itself can distort timings; benchmark with instrumentation disabled when comparing speed.
- Practice: Select profiling.sampling for a long-running server and profiling.tracing for exact call counts in a short helper.