Some comments from a non-developer:
The proposal to add this to 3.x seems a bit premature until you have a
version that runs with 3.x. Not that I expect that to be a problem though.
If CPython development moves to distributed hg, the notion of 'blessed'
branches (other than the PSF release branch) will, as I understand it,
become somewhat obsolete. If you make a branch publicly available,
anyone can grab it and merge it with their branch, just as they can with
anyone elses.
3.x add optional type annotations. It seems to me that a 3.x proposal
should make use of those.
All the info being collected for every byte code execution *must* take
extra time, which will slow down certain types of programs.
Given the slight benefits compared to the costs, I think this, in its
current state, should be optional, such as is psyco.
Psyco has a similar time-space tradeoff, except that the benefit is much
greater (10x+ has been reported by happy users) for certain types of
code (lots of integer arithmethic, which psyco unboxes). Why should your
changes be blessed and psyco not? While now 2.x only, like UnSw, there
are apparently people working on a 3.x version. Pysco makes its
tradeoffs voluntary, and easy to switch on and off where the benefits
are worth the cost to the particular user. I do not think that standard
CPython should be made incompatible with a module that greatly benefits
certain users who have been using it for years.
Your results suggest that speeding up garden-variety Python code is
harder than it sometimes seems. I wonder how your results from fancy
codework compare, for instance, with simply making built-in names
reserved, so that, for instance, len = <whatever> is illegal, and all
such names get dereferenced at compile time.
Increasing startup time on a hot new machine from .2 to .3 sec may not
be a big deal, but increases from 2 to 3 secs on an older machine will
be for short scripts that execute in 2 secs anyway.
I guess what I am mainly saying is that there are several possible ways
to speed up Python 3 execution (including others not mentioned here) and
it is not at all clear to me that this particular one is in any sense
'best of breed'. If it disables other approaches, I think it should be
optional for the standard PSF distribution.
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
