What I like about profiling.tracing is how you can control it in the same code base that you are profiling. That turns tracing into a feature you can ship, not just a tool you can attach. Profiling.sampling doesn't seem to provide anything similar, it has to run as a separate process
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.
I'm not trying to criticize, but Python is known to be much slower than eg. Java or Go etc. So for performance-critcal code, why use Python? I find Python to be very good because it is concise and simple, but I have not used it for production so far.
You use Python when it makes sense for other reasons (library support, coworker familiarity, etc), same as for any other project. Additionally, sometimes performance matters, but perhaps not enough to overcome whatever else is drawing you to Python in the first place.
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 simple answer is, I choose to use Python because I am productive with it. I get a lot done compared to the other languages I have tried. Performance is almost never the limiting factor in my work, nor has it been for the vast majority of the work I've ever been witness to. When it is, it comes up in very particular circumstances, and can usually be fixed algorithmically. Indeed, that is the situation where I have used profilers.
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.
> I choose to use Python because I am productive with it.
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.
> I think many developers are productive in one language: in the one that they know best.
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.
I think it's the opposite, the fact that it is slow means profiling is more important. This is because a 10x difference between unoptimized 0.1ms and optimized 0.01ms in Go could translate to 10s vs 1s in an equivalent python script, which is considerably more noticeable difference
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.
Profiling is about acknowledging hot paths. What to do with that info is up to programmers - usually trying to optimize code that takes more execution time than expected. Every language needs good tooling, no matter how fast its runtime.
I wrote a logistics optimization program (think travelling-salesman++) in Python and it gradually took over from the v1 version written in Java.
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.
It's super easy. If you collaborate with non-software people (say, in hardware engineering), there's not many good alternatives. I've seen attempts at DSLs, Lua, and Perl, C (disaster) but Python lets anyone dig down and understand/debug.
Generally you choose Python for the conciseness you mentioned, and then move the performance-critical functions into another language like C or (I find to be easiest) Cython. Ideally most of your code stays Python, and you either optimize self-contained pieces, or find library bindings that have done it for you.
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.
In production what's making your application slow is extremely unlikely to be the python code. It's going to be I/O, the threading/concurrency architecture, other mistakes or inefficiency that can be cleared up without leaving the ecosystem. The question of fast vs. slow languages doesn't make a lot of sense to entertain before you have any context of the specific needs of the application or use case. On its own it's just unsophisticated vanity blog fodder.
With the obvious caveat that low-level game engine, image/video processing, numerical code etc. isn't really viable in Python. But outside of that, it's fast enough for gluing together other code that's doing the heavy lifting.
Right, if you're writing an Xbox game for example you wouldn't go with Python but if you're in the range of use cases where a language isn't fully disqualified then the pure speed of the language itself rarely needs to guide the decision.
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
Interesting, does wall-time mode work with Asyncio?
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?
What I like about profiling.tracing is how you can control it in the same code base that you are profiling. That turns tracing into a feature you can ship, not just a tool you can attach. Profiling.sampling doesn't seem to provide anything similar, it has to run as a separate process
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.
I'm not trying to criticize, but Python is known to be much slower than eg. Java or Go etc. So for performance-critcal code, why use Python? I find Python to be very good because it is concise and simple, but I have not used it for production so far.
You use Python when it makes sense for other reasons (library support, coworker familiarity, etc), same as for any other project. Additionally, sometimes performance matters, but perhaps not enough to overcome whatever else is drawing you to Python in the first place.
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 simple answer is, I choose to use Python because I am productive with it. I get a lot done compared to the other languages I have tried. Performance is almost never the limiting factor in my work, nor has it been for the vast majority of the work I've ever been witness to. When it is, it comes up in very particular circumstances, and can usually be fixed algorithmically. Indeed, that is the situation where I have used profilers.
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.
> I choose to use Python because I am productive with it.
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.
> I think many developers are productive in one language: in the one that they know best.
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.
I think it's the opposite, the fact that it is slow means profiling is more important. This is because a 10x difference between unoptimized 0.1ms and optimized 0.01ms in Go could translate to 10s vs 1s in an equivalent python script, which is considerably more noticeable difference
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.
Profiling is about acknowledging hot paths. What to do with that info is up to programmers - usually trying to optimize code that takes more execution time than expected. Every language needs good tooling, no matter how fast its runtime.
I wrote a logistics optimization program (think travelling-salesman++) in Python and it gradually took over from the v1 version written in Java.
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.
It's super easy. If you collaborate with non-software people (say, in hardware engineering), there's not many good alternatives. I've seen attempts at DSLs, Lua, and Perl, C (disaster) but Python lets anyone dig down and understand/debug.
Generally you choose Python for the conciseness you mentioned, and then move the performance-critical functions into another language like C or (I find to be easiest) Cython. Ideally most of your code stays Python, and you either optimize self-contained pieces, or find library bindings that have done it for you.
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.
In production what's making your application slow is extremely unlikely to be the python code. It's going to be I/O, the threading/concurrency architecture, other mistakes or inefficiency that can be cleared up without leaving the ecosystem. The question of fast vs. slow languages doesn't make a lot of sense to entertain before you have any context of the specific needs of the application or use case. On its own it's just unsophisticated vanity blog fodder.
With the obvious caveat that low-level game engine, image/video processing, numerical code etc. isn't really viable in Python. But outside of that, it's fast enough for gluing together other code that's doing the heavy lifting.
Right, if you're writing an Xbox game for example you wouldn't go with Python but if you're in the range of use cases where a language isn't fully disqualified then the pure speed of the language itself rarely needs to guide the decision.
Because your colleagues insist on it and now you're stuck with slow Python despite telling them that this is exactly what would happen...
This sounds a lot like py-spy. How does it compare?
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
Thanks for py-spy, it's awesome!
wiwm i'd imagine it has a 3rd party tool. very nice to get it out of the box in 3.15
Interesting, does wall-time mode work with Asyncio?
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?