Tim Peters wrote: > > [M.-A. Lemburg] > > ... > > Running the same test for 2.1 vs. 2.0 there's not much to > > notice, so the important changes seem to be originating in > > the move from 1.5.2 to 2.0. > > IIRC, Guido, Skip Montanaro and I put major effort into finding speedups for > 1.5.2, and Fredrik did more independently (like inlining high-frequency int > operations in the eval loop). Also IIRC, that's the last time any concerted > effort was put into speeding Python. 1.5.2 was an efficiency peak, then, and > unstable equilibrium never endures without deliberate and persistent > rebalancing work. If Python were "a real product", it would be at least one > person's full-time job to keep it in peak shape. But it's not even a > part-time job for anyone, and I don't see that changing. In compensation, > machines have gotten faster much quicker than Python has slowed. How about making performance the main "feature" for 2.3 then ?! 2.0 - 2.2 introduced many new features in the interpreter core, so I think it's time to stabilize those features and focus on making Python regain the performance it had before those features were introduced. At least to some of us, performance is an issue and I think that there's a lot we can do to improve it. One way to open up the field for better performance will be to modularize the interpreter, so that new ways of optimization can be explored, e.g. truning the VM a register machine (Skip once started looking into this with his Rattlesnake patches) or creating specialized VMs which can then be used by optimizing compilers as targets. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4