> One thing that bugs me: the article says 3 or 4 times that Python is
> slow, each time with a refutation ("but it's so flexible", "but it's
> fast enough") but still, they sure seem to harp on the point. This is
> a PR issue that Python needs to fight -- any ideas?* Ask a prominent PSF member, ESR, to stop bagging on that point in his book (python is much faster since he wrote it and Moore's law has made it less of an issue over time). Py1.5.2 running on a 133Mhz 386 is not the same beast as well designed Py2.4 code running on a 3Ghz Pentium IV (also I would argue that many apps are computationally bound anyway). * Have python.org prominently feature an article of Python's use in high-performance environments. IIRC, somebody wrote a realtime voice over internet system and found that with good design, there was no speed issue. Also, the cellphone apps may make a good example. * Another prominent developer and PSF member wrote a much publicized, unfavorable log entry basically saying that he was unimpressed with Py2.4. While that log entry was subsequently revised, it did serve as anti-advocacy. Also, my request was denied for better presentation of performance related benchmarks in the widely read What's New document. Right now, it features somewhat unimpressive and misleading pystone results. Were we to show comparative pybench results 2.0 to 2.1 to 2.2 to 2.3 to 2.4, it would become clear that some of the performance concerns are out of date. Parrotbench and test_decimal also reveal some modest gains over 2.3. * A ZDNet reporter had setup a phone interview with me but did not follow through. I had planned to nip the issue in the bud by focusing on the Py2.4's vastly improved scalability: - The trend toward use of iterators, generators, generator expressions, and itertools scale-up well because of their superb memory performance and ability to save state. Apps using generators and genexps save all the time that was formerly lost to accessing instance variables. And apps keying off of itertools can sometimes completely avoid interpreter overhead. IOW, Py2.4 provides a strong toolset for writing clean, high-performance apps with a minimum of development time. - Behind the scenes, almost every important building block has either improved algorithms, memory optimizations, speed optimizations, and/or has been rewritten in C (while still preserving their pure Python equivalents). The bytecodes get optimized for speed and readability, and the eval-loop itself is tighter. Lists initialize, append, pop, and extend much faster and are more conservative with memory. List comps are up to twice as fast. Dictionary iteration is speedier. Sets, bisect, and heaps now have C implementations like other basic building blocks. All of the fifo queues in the library now use an O(1) algorithm instead of O(n) -- this improves scalability for everything from threading and queues to mutexs and asynchat. * Any PR effort should also emphasize that no usability trade-offs were made along the way. A number of features make Py2.4 easier to use than 1.5.6: list comps, genexps, generators, sets, nested scopes, int/long unification, decorators, etc. Some might argue that it takes a modicum effort to learn listcomps, generators, and decorators, but they cannot make any bones about the cleanliness, simplicity, beauty, and speed of the resulting code. Python will always lead in maintainability and development time. * Python's website has traditionally been self-centered, leaving others to have to make the case for their own products. Perhaps, it is time to change that. Those who really care about speed cannot make a balanced decision about Python without considering psyco, pyrex, numpy, and the like as part of the total development environment. * There is another angle that is difficult to present but a reality never-the-less. It is easy to write toy C / C++ code that is blazingly fast. However, when you add error checking, fault tolerance, interaction with real world, etc, the code gets slower. Also because that code is harder to write, it is somewhat common to use crummy algorithms (linear searches for example). I really liked Tim's comment that code using Python's dictionaries runs 10,000 times faster than anything written in any other language. That seems to get to the point across well enough. * A bit of good news is that the upcoming Python cookbook will make a strong case for Py2.4 being a tool of choice for those who care speed, space, maintainability, and development time. It is a nice, highly visible bit of advocacy. * One last thought. Articles will always pick on something. It's not really a terrible thing to have someone say the superb productivity gains come at the price of running slower than C. I would much rather hear that than have people bag on the docs or standard library or launch into a diatribe @decocrator destroying the beauty of the language. Raymond _______________________________________________ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
