Isaac Gouy wrote: >>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?
But that is a stupid context. It doesn't really tell us anything. Slow at what? No one writes a program for the purpose of doing loops, comparing integers, setting up stack frames or jumping between instructions. The context for programming typically involves solving some problem or executing a function that matters to the user. It's just as database benchmarks. TPC C benchmarks tells us how fast a certain database is at performing TPC C benchmarks. Does that tell you anything about how fast it will be compared to competing products for your real world problem? Probably not. Which ever product you choose, you might end up with situations where a particular function is too slow. You can typically solve this either by changing the code or the configuration of the server. Sometimes you have to rethink your system and solve the problem in another way. Changing from e.g. DB2 to Oracle is unlikely to have more impact than these smaller changes. It's the same thing with most software development. >> 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? They are more or less useless for anyone who wants to decide what programming language to use in a real world situation. It's simply stupid to implement sorting algorithms in Python. It's there already. Solving Ackermann's is also rather far from what people typically want to achieve. If people actually had the time and resources to create real software products, (i.e. things that take man-months to create) from the same spec, and developed e.g. ten programs each each ten different programming languages in cleanroom conditions, we'd probably learn something useful about the usefulness of a certain type of programs with certain programming languages in certain conditions, but only in these conditions. I'm rather certain that aspects such as team size, development methodology etc will influence the relative ratings of programs. I'm not saying that the typical toy benchmarks are completely useless. They might tell us things about particular language features that should be improved, or give us clues that a certain way of solving a particular problem etc, but they don't really help Joe Newbie Programmer who wants to write yet another web site toolkit. -- http://mail.python.org/mailman/listinfo/python-list
