Profiling.sampling – Statistical Profiler (opens in new tab)

It’s not a downside perhaps but a tradeoff. Implementing internal sampling profiler is not impossible in general (though it will depend on exact python implementation) but it would impose different overhead on the target and might skew results a lot more than external one.

Even when performance is not critical it’s possible to write (or vibe?) disastrously slow code, so having profiler handy is always a plus. It might be a deciding factor between “we must rewrite it all in Rust” and “oh we added exponential complexity by accident” and save a ton of time

Sometimes you get there by accident. You make a thing, it grows or is used in unexpected ways, now suddenly performance matters.

Sometimes Python is just the language used in the domain. Lots of sciences live on Python because it is easy to teach to grad students and the package ecosystem is strong.

While there are some implementation differences (py-spy is written in rust, profiling.sampling is a mix of python and C etc), the end result seems pretty similar to me.

One thing to note is that there are some differences in blocking behaviour of the target process. Py-spy blocks by default and profiling.sampling doesn't. I wrote a bit about why py-spy blocks by default here https://www.benfrederickson.com/why-python-needs-paused-duri... - the first version of py-spy also didn't block and since we got incredibly misleading results at times this was one of the first changes I made to py-spy