Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

hackernoon.com

Post reply on HN
Print view View original

101–110 of 206 posts

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

#101

Post by agentgt »

pg314 wrote: post #54
agentgt wrote: post #29

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

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

Its interesting you mention CSV as I had an issue with CSV with Java many years ago.

I was trying to cut a couple of columns out of a CSV and tried to write it in Java and for some reason either the CSV library was slow or maybe I didn't have the right buffered input but I ended up writing a python script that outperformed my Java code (which reminds me I meant to revisit that).

Anyway here is the python code (it might not be the exact code I used as I didn't update it but whatever):

https://gist.github.com/agentgt/1383185

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

#102

Post by TuringTest »

golergka wrote: post #92
barrkel wrote: post #58

Earlier quoted context omitted.

You sound like someone who hasn't used dynamic languages in anger, or you'd mention some of the things that dynamic languages do well that statically typed languages aren't so great at, to prevent your argument sounding like a straw man. For example: dropping into a debugger (binding.pry / pry_remote in Ruby) to write code interactively in the context of the application, transferring that code to the source, and cont…

You're describing tools usable in writing new code. What static languages thrive in, however, is maintaining old code that was written by somebody else.

Which is the reason why it makes sense to write new applications in a dynamic language, and later port critical parts of it to more static compiled ones.

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

#103

Post by dahart »

Python's value to me has always been that it's easier to get things done, not it's speed. One time when I was interviewing a candidate for a coding job, the candidate said she loved Python the most "because you can just yell at it and it'll work."

It's both the breadth of the standard library and ecosystem, and the simple language design, that make developing things in Python faster for me.

Doing problems on Project Euler has been an education for me in how algorithm matters more than speed. Lots and lots of people spend hours writing long C++ codes that are easily beaten by a few lines of Python. It certainly goes the other way too, and the wrong algorithm in Python is even that much slower and more painful than the right algorithm in C++. But when the right algorithm is used and the problem is solved in a few milliseconds, it really doesn't matter which language uses more CPU cycles, all that matters is whether you saw the insight that let you skip 99% of the search space, and how much time you spend writing code.

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

#104

Post by hellofunk »

Jtsummers wrote: post #98
hellofunk wrote: post #86

Earlier quoted context omitted.

You are talking about a function (at runtime), not a type, verifying the range. And you can do that in any language, regardless of its stance on typing.

http://www.adaic.org/resources/add_content/standards/05aarm/... Compile-time and run-time floating point numbers constrained by precision and range. It's been a long time so I'm just going to include the examples in that document: type Coefficient is digits 10 range -1.0 .. 1.0; type Real is digits 8; type Mass is digits 7 range 0.0 .. 1.0E35; subtype Probability is Real range 0.0 .. 1.0; These will be checked (to th…

Cool, but I don't know much about Ada, and would like to see an example for a statically-typed "range checker" in a more mainstream language used actively today. C++ templates can do a lot of magical stuff at compile time but such techniques are well beyond the reach of most developers.

I can't think of any typed language I've used or seen in active modern professional work where you could validate a value as part of a type at compile time.

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

#105

Post by lyschoening »

scarface74 wrote: post #20

I was all ready to savage his opinion after reading the headline but I agree looking at my architecture that I designed for the company I work for, CPU isn't the bottleneck. Every time I try to increase performance by multi threading as much as possible, the databases start screaming. On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages…

From my experience, statically typed Python is quite a bit slower to write. It pays off for modules that see a lot of use in the codebase, but typing every bit of code can be a lot of work for little gain.

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

#106

Post by progman »

Yes, time to market is important. However, you don't need to compromise convenience of development for the sake of performance. If you twist your Python code to get performance it takes time. If you need performance, and like the syntax of Python then you should take a look at Nim [1]. With Nim I develop as quickly as in Python while I get the performance of C.

[1] https://nim-lang.org

I believe application performance is important on servers. It makes a difference if your Shop software written in Python is able to handle 50 requests per second, or if the same software written in Nim can handle 500 rps. And by the way, Nim provides static typing which helps a lot to catch errors at compile time.

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

#107

Post by agentgt »

nhumrich wrote: post #99
agentgt wrote: post #93

Earlier quoted context omitted.

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

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

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

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

#108

Post by mattkrause »

classybull wrote: post #88
pg314 wrote: post #54

Earlier quoted context omitted.

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

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

You'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.

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

#109

Post by dahart »

et2o wrote: post #97
dahart wrote: post #89

Earlier quoted context omitted.

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

Wouldn't numpy be the default choice for this type of work in Python?

Yes, 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.

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

#110

Post by fiddlerwoaroof »

shakna wrote: post #80
scarface74 wrote: post #20

I was all ready to savage his opinion after reading the headline but I agree looking at my architecture that I designed for the company I work for, CPU isn't the bottleneck. Every time I try to increase performance by multi threading as much as possible, the databases start screaming. On the other hand, the idea that dynamic languages are more productive than static languages are laughable. Statically type languages…

> You can't even reliably do a "find usages" of classes using a dynamically typed language. Let me introduce you to Racket. It started out in life as Scheme, and became something more. DrRacket, it's IDE, is fantastic. The main reason why? You can trace every function call, and every macro, to its definition with a quick mouse-over, even if said definition is in another file or library, even if said definition is onl…

Yeah, Common Lisp, Racket and Smalltalk all are dynamically-typed languages that offer these sorts of features. Racket can solve this through its powerful reader/macroexpander. The others do it by having you develop inside your run-time environment where you can take advantage of all sorts of interesting information only available at run-time.
Post reply on HN