Is python very slow compared to C

[Isaac Gouy]

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.