6 ms·
Unless we are talking like circa 1999 I don't think I have heard a complaint yet that Python is slow. I'm curious who or where the author heard that from (not s
by agentgt 9y ago
Unless we are talking like circa 1999 I don't think I have heard a complaint yet that Python is slow. I'm curious who or where the author heard that from (not specifically the people themselves but the domain they are in).
What I have heard complaints about Python are (and I don't agree with all these points):
* Its not statically typed
* The python 2/3 compatibility
* It has some design flaws: GIL, variable assigning, mutable variables, lambdas, indentation (I don't agree with all these but this is complaints I have heard).
* The plethora of packaging (ie its not unified)
I guess one could argue its slow because it can't do concurrency well but that really isn't raw speed.
Then the author started comparing string processing of programmer time from a study which... doesn't help the authors point at all.
* Python has and will always be fast at string processing and most people know this
* The people that complain about python speed are almost certainly not doing string processing
* I have serious questions about the study in general (many languages have changed quite a bit since then)
- wheaties 9y agoOh, I've heard "Python is slow" from Node folks, Java folks, Scala folks (in terms of productivity) and of course, die hard C++ fans. I'm a fan of Python but i also like languages with a stronger FP bent (and statically typed.)
- agentgt 9y ago> Oh, I've heard "Python is slow" from Node folks, Java folks, Scala folks (in terms of productivity) I have hard time believing Java folks made an argument on productivity unless you meant for that parenthetical statement to be only applied to Scala. Regardless productivity is a far more complicated than raw speed (particularly if you get into maintenance as some languages are easy to pump out code but harder to maintain... oh perl.. the pain...). And yeah I have seen the C++ folks complain about Python but this in my experience has been video game programming which is clearly not the domain the author is in or talking about (I think given the microservice discussions). Hence why I would like to know more about these folks complaining.
- rockostrich 9y agoMost comparisons of popular web development languages will show a table where every other language out performs Python (except maybe Ruby) [1]. In reality, like the author pointed out, the benchmarks don't really matter when you consider network calls. [1] https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
- nerdponx 9y agoFor some data processing tasks Python can be brutally slow, especially text processing. NumPy is only fast because it's written in C and offloads hard numerical calculations to BLAS.
- agentgt 9y agoYes but at least Python has very good native access to libraries. For example I am sure Java is faster at numerical processing than pure Python at least with Python you have the option of writing in native. Python has really good C interop and it maybe considered by some not part of the language but I consider that it is. Yeah you could write native code for Java via JNI but its not easy (granted its been a while) and for reasons I can't remember why but JNI is slow (probably moving stuff on and off the heap... I can't recall).
- AstralStorm 9y agoDecent, not very good. Ctypes is slow, cython requires extra boilerplate to become performant. Python/C API is even more annoying than that. (Compared even to something like JNI.)
- pg314 9y ago> I'm curious who or where the author heard that from (not specifically the people themselves but the domain they are in). In the telecom domain, I've dealt with data big enough that Python wasn't really feasible. Think 100 of millions of records in CSV format that need to be parsed and processed. Doing that in Python is going to be painful.
- classybull 9y agoPython is insanely fast at data processing and analysis because it has very fast libraries. As a matter of fact, don't know if you've heard, but data processing it kind of like.. Python's thing...
- mattkrause 9y agoYou're violently agreeing with each other. Python itself can be pretty slow. Doing image processing on data stored as list-of-lists-of-integers would be brutally slow. On the other hand, numpy is an import away, and it can be quite fast, especially if it's been built with an optimized BLAS/ATLAS, etc.
- AstralStorm 9y agoBy blazingly fast you mean 100x slower than C++ equivalent and only 20x slower is you're very careful to avoid accidental copies. For reference, MATLAB is about 30x slower with no special care. Pure Java on Hotspot was 5x slower except it dies on big data input due to very slow GC and goes to 50x slow. Source: handled big audio data from hdf5 database, gigabytes sized. C++ equivalent had no vectorization or magic BLAS or anything.
- joshuamorton 9y agoAs I'll often say to these comments, then you're doing things wrong. Numpy code can be written to never leave the numpy sandbox, and at that point it should be as fast or faster than naive c++ (because you'll be getting SSE and stuff for free). There's a reason almost all deep learning is done in python.
- Acalyptol 9y agoCould you elaborate on what are the complaints you've heard about "variable assigning, mutable variables, lambdas"? Just curious.
- agentgt 9y agoIt unclear if you are introducing a new variable to the scope or mutating an existing one. # Am I defining foo for the first time or am I mutating foo = "stuff" Python if I recall in the OOP sense combats this with requiring self.foo but this is not the case with other forms of lexical scoping such as loops with in loops etc. And of course you can't define constants. IIRC for lambdas its that they can't span multiple lines and I believe they are getting removed (I'm not a python 3 expert)?
- nhumrich 9y agoAuthor here. I mostly work with a lot of Java devs. They are hesitant to try python because "java is faster". Some use the static typing excuse, but oddly, the most common reason I hear people wont do python is because its "too slow". Perhaps I live in a weird bubble, but that's the motivation behind the article.
- agentgt 9y agoI'm a Java dev (and the one you replied to) and in the past when I didn't work at my own company the real reason Python was often not picked was because it was considered "a toy language" or "scripting language" (ie hard to maintain) and also because it didn't have vendor support like Java did. Of course this was like 8-10 years ago. I still program and sadly prefer writing code in Java over Python even though I have tons of Python scripts in my ~/bin that I have written over the years. Mainly because I just know the ecosphere better. And thats what most people should just admit why they choose a particular programming language. As long as its good enough... better... is just what you know more of... the cost of learning something new just to replace something new for marginal speed increase isn't worth it. So when people say Java is slow to learn, not cool or slow to develop in because the language is verbose... I say just like you: "I Dont' Care" because learning the whole ecosphere of another language is goddamn expensive (that is languages are relatively easy to learn but all the libraries, best practices and tools is another thing entirely).
- nhumrich 9y agoThats a very fair argument. But lets say hypothetically that language X was more "productive" than language Y. Wouldnt it be a worthwhile "investment" to learn X seriously? Sure it might slow you down for a year, but after that it pays dividends.
- agentgt 9y agoYes of course and for my own personal projects I will take the time often to learn new languages (e.g. Rust). However when dealing with a team often with an existing code base getting everyone on board with "X" while potentially porting to "X" is fairly expensive. Its generally only worthwhile because of actual technical limitations and not productivity. Even the promise of safety (ie prevention of bugs) I would probably consider higher than productivity (although I suppose that is in way productivity). Regardless productivity is really hard to measure and especially predict unlike other technical things.
- odiroot 9y ago> * Its not statically typed Yes, that's why we use it.
- dahart 9y agoI'd agree with all the complaints you list, and I love Python, but it is definitely kinda slow. I'd put the speed of python below several of the items on your list in terms of priorities I care about. I've done a lot of image processing in Python using libraries like PIL, numpy and opencv. Doing per-pixel operations is extremely easy in PIL - improving my dev time, but CPU wise the slowest of the bunch. I love prototyping that way, but I have to move to numpy or opencv or another language to speed it up. A recent program to do a slightly complicated color transform on a 512x512 image was taking me over 60 seconds with PIL. It was 5-10 seconds in JavaScript, and less than 1 second using numpy.
- et2o 9y agoWouldn't numpy be the default choice for this type of work in Python?
- dahart 9y agoYes, if you care a lot about performance. But there's a cognitive cost to numpy for me because I'm not completely fluent. It's much more difficult to prototype something, so I usually wait until I've iterated on a prototype and I know exactly what I want to do before I dive into numpy. Numpy also has an inside-out order of operations compared to using vanilla Python, the reason it's fast is because you put the inside of the loop on the outside of the code. That can make it really hard to iterate on structural changes in your code. You can lose a lot of the dev time advantages by going numpy first. Also a lot of people don't consider numpy to be a fair comparison when talking about Python's language performance. Because it's optimized compiled code underneath the Python binding, it's not representative of the speed of the Python interpreter.
- bane 9y agoPython is very developer productivity friendly, but degrades performance in weird ways and the methods to increase performance don't always make lots of obvious sense and often are the "idiomatic" way. I haven't looked into the guts myself, but I'd bet that for similar or equivalent operations, the way the different syntaxes are handled under the hood are wildly different. e.g. function calls are much faster than method calls on objects. Optimized pure python can look very ugly and non-idiomatic.