Steven D'Aprano wrote: > On Sun, 12 Feb 2006 03:03:20 -0800, bearophileHUGS wrote: > > > Steven D'Aprano>Very slow to do what, compared to what? The decay time > > of the tau meson?< > > > > Probably every answer I can give you is wrong for you, so answering is > > almost useless... > > We do actually agree. You did explain why the speed of the language itself > is rarely the critical factor. My criticism is that whatever good your > post would have done was nullified by your opening comment stating that > Python is very slow -- a comment which I think is not only harmful, but > wrong, benchmarks like the one you linked to not withstanding. > > I think it is wrong to call Python "very slow" just because it is slower > than some other language or languages, for the same reason it would be > wrong to describe the population of the UK as "very low" because 60 > million people is a smaller number than China or India's one billion plus. > Doing so merely reinforces the premature optimizer's message that any > language that isn't C (and sometimes Lisp) is "not fast enough".
There was some context: Is python very slow compared to C? With similar context your example becomes: Is the population of the UK very low compared to the population of China or India? (Which seems to be a reasonable question.) We can make the missing context in the OP's question more obvious like this: Is the population of the UK very /slow/ compared to the population of China or India? > The benchmark you pointed to are of limited use for application > developers. (Their value to language designers is another story.) Limited use for what purpose? (Yes it really is difficult to make all our assumptions explicit in our writing.) > Given > that Ocaml is (say) 200 times faster than Python on average, it tells the > application developer virtually nothing about the performance of his > application. And that's what user's care about -- they couldn't care less > about binary trees or partial sums, they care about how long it takes to > render a JPEG, open an email, save their files, query the database, > display a window, and so forth. Few application level tasks are limited by > the speed of the language, not these days. As in http://shootout.alioth.debian.org/miscfile.php?file=benchmarking&title=Flawed%20Benchmarks > > You don't believe me? Consider the following: > > When you drag your mouse over text in a graphical text editor, the text > highlights. How much money would you be prepared to pay to make that > highlighting occur 200 times faster? $100? $1? One cent? Chances are you > wouldn't pay a thing, because it is already fast enough, and making it > faster is of zero value to you -- even if highlighting ten gigabytes of > text might be uncomfortably slow. > > What about opening an email? How much would you pay to reduce the time it > takes to open and display an email from a hundredth of a second to > virtually instantaneously? I suggest that most people would consider 0.01s > to already be be "virtually instantaneously". > > The important question isn't "is Python fast or slow?", it is "is Python > fast enough?". That's a question that doesn't have a simple answer, > because it depends. Fast enough to do what? > > But, in general, more often than not, Python is fast enough. The extra > value of using something like Lua or Ocaml or even C is just not enough to > make up for the disadvantages of using those languages. Seems like you're having your cake and eating it too - if it's meaningless for others to talk in generalities about fast or slow, and it's just as meaningless to talk in generalities about 'more often than not'. > > Of course Python isn't always fast enough. Please don't waste your time > coming up with practical examples where pure Python is objectively too > slow for a certain task, because you won't be telling me anything I don't > already know. > > But the developer doesn't have to write pure Python, he can call a module > written in C, or change the algorithm, or find another way to accomplish > the same end result. Or even decide that for this specific task, Python is > not the language to use. These are all good solutions, but they don't mean > that Python is "very slow" in general. Even C is not always fast enough, > but we wouldn't say C is "very slow" just because it can't calculate the > first million Mersenne Primes in twenty milliseconds. > > > -- > Steven. -- http://mail.python.org/mailman/listinfo/python-list
