Profiling.sampling – Statistical Profiler
docs.python.org
docs.python.org
Right this second I'm writing something in Python with critical performance requirements. It needs to average processing 25k things per second. That won't be particularly hard, but it's close enough to the edge of what the language is capable of that I do need to be at least a tiny bit careful with the implementation. I'm highly unlikely to need a profiler for this project in particular, but earlier in my career I probably would have needed one.
Python is fairly commonly used as a glue engine around faster code too, and it's not always obvious when the wrapper code is inducing nontrivial overhead (hidden copies and that sort of thing). Profilers are great for teasing out those sorts of problems. They shine a spotlight on the section of code which should take 0us and is instead dominating your runtime.
The fact that the base language is an order of magnitude (or two!) slower has almost never mattered. If my work gets to the point where it does, and I have an excuse to go mess around with a rust extension or some cool optimized library, things are going very well.
I've been professional developer for over 20 years now, and I've read this forum obsessively for much of that time. I've seen people write things like, "Most engineers would kill for a 5% speedup" and I think, on what planet? Most engineers have much larger problems that cannot be so easily quantified. Come to think of it, I think that there is an allure to performance optimization due to the fact that it can be so easily quantified.
That, I fully understand. I think many developers are productive in one language: in the one that they know best. Which is probably the one they use most. It might happen that this is is a "fast" language by accident (like Java or Go), or a language like Python. And then there is never enough reason to switch.
> "Most engineers would kill for a 5% speedup"
I think this is very rare - maybe a heavily used app in Facebook or Google, where 5% could mean a lot of money. But a factor of 10 speedup is much more common (and possible sometimes).
> there is an allure to performance optimization due to the fact that it can be so easily quantified.
That's true. I also think simplicity is quantifiable, and so my personal hobby is to write something impressive in few lines. Like a chess engine, QR code reader, editor, data compression tool, compiler, in 500 lines. But this is mostly for hobbies I guess. For work, it's mostly about features, and then performance, I guess.
While superficially true, this conflates cause and effect. I am, or was at one time, extremely proficient in multiple assembly languages, Fortran, C, Pascal, Modula-2, Verilog, and Python, marginally proficient in multiple other assembly languages, Perl, Tcl, etc., and have toyed with various lisps and functional programming languages.
I viscerally recoiled from a few languages, like Java, Javascript, and C++, and found other languages, like Go, Lua and Julia, not compelling enough to bother switching to for my use cases.
And while I can certainly believe that many people are most productive in the language they know best, that most emphatically doesn't mean that they learned a language and became proficient in it to the exclusion of others. It most certainly meant in my case that I spent more time with, and learned ever more about, a language that was already productive and useful for me.
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.
People generally compare "speed of execution" to "speed of coding".
I'll add "speed of troubleshooting". When something goes wrong and the clock is ticking, you need tools to identify quickly if the data is inconsistent, a config set wrongly or the algorithm stuck at a local optimum. And then decide if things can be mitigated with a patch or we should we grovel and buy time from the client... All of this is much easier in Python (bar the grovelling).
LLMs are changing things though. I recently ported a complex part of the kernel to C++. 90% of it was creating the scaffolding before the actual algorithms were ported. Very tedious work but Claude can just chug through. Wouldn't like to maintain it just yet.
A profiler like this can be used to identify which parts to rewrite in a faster language. Sometimes it's easier to write everything in Python first, then measure, than guess at the start which parts need to be fast.
You can also get gains by switching algorithms, both in pure Python and when using a compiled library like `numpy`. And there are also some operations, like string manipulation or the `sqlite3` module, where the Python runtime's implementation has already been optimized in a compiled language.
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
Imagine if I have a single request calling asyncio.gather() on 5 different coroutines. Only 1 is on CPU, the other 4 are on IO. Is Tachyon able to sample all 5 coroutine tasks?