42 ms·
It is easy to miss the point with such articles. OP touched upon it in chapter "So Why Use Python?". Raw speed, while sexy, is not a deciding factor in most cas
by amenod 10y ago
It is easy to miss the point with such articles. OP touched upon it in chapter "So Why Use Python?". Raw speed, while sexy, is not a deciding factor in most cases - not everybody is working on HFT. And when it is important to be really fast, you can always write an extension in C (or Rust I imagine?) just for that single tight loop and get raw speed without sacrificing maintainability. Seriously, most bottlenecks (in other people's software of course ;) I came across were either due to bad architecture or unreadable code, which lead to not noticing that too much work was being done. So yeah, Python might be slower than alternatives (though I have a hard time believing that it is slower than Java), but it is fast enough.
- cwyers 10y agoOh, the crippling sense of irony that comes from reading this comment after reading the front page post about Azul and the JVM, with a lot of technical details about how HFT firms use Java.
- amelius 10y agoThis might certainly be true for single threaded programs. For multithreaded programs, Python has a bottleneck known as the "Global Interpreter Lock" (or GIL), which is not so easily optimized away, unfortunately.
- amenod 10y agoTrue, though this is not the kind of speed this article was talking about. You can get around that limitation somewhat by using multiprocessing module. I'm not saying Python is the best language of all, but dissecting Python bytecode is kind of missing the point. Python's strong point is its ease of use.
- d0mine 10y agoGIL may and does get released in the interpreter (on I/O) and C extensions such as regex, lxml, numpy. Performance sensitive extensions may even use multiple CPU cores implicitly e.g., as numpy.dot() can do for large enough input without changing the code in any way.
- retrogradeorbit 10y agoYes, leading to C extensions that are not thread safe and so can't be used in multi-threaded code at all. An example I'm familiar with is pylibmc.
- d0mine 10y agoWrong. GIL does NOT necessarily make your Python/C code thread-safe and in reverse releasing GIL does not prevent you from writing a thread-safe code.
- nitsujin 10y agoAre you kidding? Java is much, much faster than Python.
- satysin 10y agoJava absolutely destroys Python when it comes to speed comparisons.
- curried_haskell 10y agoThe only reason people might think of Java as slow, is because of desktop applications like LibreOffice, IntelliJ, or Eclipse. Java on the server blows Python out of the water in terms of speed.