Yes, Python is Slow, and I Don’t Care
hackernoon.com
Yes, Python is Slow, and I Don’t Care
1–10 of 206 posts
Re: Yes, Python is Slow, and I Don’t Care
#2Fast prototyping is great but being stuck with a prototype for deployment isn't.
Re: Yes, Python is Slow, and I Don’t Care
#3The problem is not so much that python is slow. It's that in some scenarios python can't be made fast. Fast prototyping is great but being stuck with a prototype for deployment isn't.
So given that, can you elaborate on your objection? I'd like to know why you think the article is wrong about optimising your Python to make it fast enough.
Re: Yes, Python is Slow, and I Don’t Care
#4The problem is not so much that python is slow. It's that in some scenarios python can't be made fast. Fast prototyping is great but being stuck with a prototype for deployment isn't.
Re: Yes, Python is Slow, and I Don’t Care
#5I've found that this is often the case. Nearly always disk or network. But it's sometimes surprising how little work you need to do to become CPU-bound. This is the price we pay for such a tremendously dynamic language.
Indeed, the article's suggestions of C/Cython/PyPy are good ones to remedy the problem when it occurs.
Re: Yes, Python is Slow, and I Don’t Care
#6The problem is not so much that python is slow. It's that in some scenarios python can't be made fast. Fast prototyping is great but being stuck with a prototype for deployment isn't.
Can you give some examples of this? I mean, obviously with enough effort you can "make python fast" since it has good C bindings, and can just be a thin wrapper around fast stuff. Similar to how command line tools can be ridiculously fast[^1] despite, ostensibly, running in bash.
So I'm a bit confused about what you're claiming. Organizational issues, it's difficult to get management on board with an optimization pass?
[^1]: https://aadrake.com/command-line-tools-can-be-235x-faster-th...
Re: Yes, Python is Slow, and I Don’t Care
#7The problem is not so much that python is slow. It's that in some scenarios python can't be made fast. Fast prototyping is great but being stuck with a prototype for deployment isn't.
Re: Yes, Python is Slow, and I Don’t Care
#8The problem is not so much that python is slow. It's that in some scenarios python can't be made fast. Fast prototyping is great but being stuck with a prototype for deployment isn't.
>It's that in some scenarios python can't be made fast. Can you give some examples of this? I mean, obviously with enough effort you can "make python fast" since it has good C bindings, and can just be a thin wrapper around fast stuff. Similar to how command line tools can be ridiculously fast[^1] despite, ostensibly, running in bash. So I'm a bit confused about what you're claiming. Organizational issues, it's diffi…
Re: Yes, Python is Slow, and I Don’t Care
#9Arguably, other languages can get code out faster depending on the dev, language, etc.
Re: Yes, Python is Slow, and I Don’t Care
#10That said, there is clearly a desire to write 'fast' code in python itself without swapping to C. Cython helps, but to get really fast Cython code you actually have to write with C-semantics (so you are basically writing C with Python syntax).
Projects like numba JIT are interesting in that they can optimise domain-specific code (i.e. numerical/array code) that's written in normal python style. It also means jumping through a few hoops (although with the latest version in many cases all you need is a single decorator on your hot function). You can even do GIL-less multithreading in some cases.
Overall things are looking promising, with the addition of the frame evaluation API and possible improvements to the python C-api that could make JIT and similar extentions easier.