Live data from Hacker News

Yes, Python is Slow, and I Don’t Care

hackernoon.com

1–10 of 206 posts

Re: Yes, Python is Slow, and I Don’t Care

#3
post #2

The 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.

Did you read the section on "Optimizing Python" ?? If so, I'm assuming you read about using CPython to migrate your package/program/module painlessly to C.

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

#5
> Your bottleneck is most likely not CPU or Python itself.

I'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

#6
post #2

The 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 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

#7
post #2

The 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.

In ten years of Python development I have yet to come across an instance where Python couldn't be made fast. In some cases critical sections had to be delegated to C but even that is very rare.

Re: Yes, Python is Slow, and I Don’t Care

#8
post #2

The 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…

[deleted]

Re: Yes, Python is Slow, and I Don’t Care

#10
Python is also heavily used in science, where performance really does matter. It's successful because of how highly ergonomic python apis can be built on top of optimised C/C++/Fortran libraries.

That 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.

Post reply on HN