[Python-Dev] Performance compares (original) (raw)
Tim Peters tim.one@home.com
Sun, 20 May 2001 08:57:11 -0400
- Previous message: [Python-Dev] Performance compares
- Next message: [Python-Dev] Performance compares
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[MAL]
How about making performance the main "feature" for 2.3 then ?!
Guido may be a dictator, but he doesn't have a magic wand -- "the main feature" is what people volunteer to do and then fight for and then actually do.
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.
"Performance" is meaningless unless quantified and made concrete: what is it that runs too slowly? "Everything" is not a useful answer. Speeding up line-at-a-time input was an example of something that worked, via focus and measurement and pushing ahead despite opposition. I doubt any other approach will bear fruit over such a short timeframe, and especially not without resources to throw at 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.
Restructure the core for the benefit of optimizing compilers that don't exist? That sounds like an interesting research project, but not much to do with making 2.3 faster. In the meantime, modularization is more likely to make the VM that does exist slower.
could-be-it's-easy-answers-or-none-ly y'rs - tim
- Previous message: [Python-Dev] Performance compares
- Next message: [Python-Dev] Performance compares
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]