> 1) If my LOAD_GLOBAL patch is no good, I'd appreciate it if you told me
> why. Looked like a pure win to me (all gain, no loss), so I'm missing
> something basic if it's not.
Looks fine to me, but the code is ages old so I may have forgotten a
subtle detail (as with continue inside try :-). I'll install it
locally and see if it breaks anything.
> 2) There was widely-expressed passionate desire for speeding the various
> forms of "name resolution" (attribute/method lookup, & so on). So I'm
> sure many would like to hear your current thinking on that. BTW, I'd
> be happy to help with implementation schemes, online or offline.
Without having firm data, I believe this discussion is getting way out
of hand. Some real inefficiencies that should be addressed by changes
to the bytecode interpreter and/or compiler are:
- method calls need to be speeded up (especially the stupid "create
a new argument tuple with 'self' inserted at the front" hack)
- function calls need to be speeded up (if at all possible avoiding
creating the argument tuple in the first place)
Also note that it may be a win to re-introduce a variant of
dictionaries that allow only strings as keys -- the generalized
version is 10-20 % slower. (This prompted me to introduce "fast
locals" as a compensation.)
I can't remember the details, but seem to remember that the last timed
I profiled Python, malloc and free calls drowned all others. I
somehow can't believe that making symbols unique will speed name lookup
that much.
Instance and class method lookup may be sped up by collapsing the
class symbol tables into the most derived class's symbol table (at the
cost of subtle semantic changes).
Donald Beaudry has a detailed proposal (and an implementation?) of a
scheme that makes builtin method lookup faster (by avoiding the linear
search).
> 3) May also be good to address Tommy's modification of the U of
> Virginia's Python to suppress printing raw expressions, so that their
>
> object.method().method().method()...
>
> style of programming doesn't flood the screen. I.e., do you really
> want incompatible versions of the language "out there" this early in
> Python's public life? I don't (I think they'll diverge more & more,
> which isn't good this _soon_), but haven't thought of a slick
> compromise short of sticking such statements on the RHS of an
> assignment. That's "reasonable" to _me_, but not to them. In all, a
> trivial issue, but maybe a tough one to resolve ...
I definitely don't want diverging language versions, and don't believe
a global switch is any good. Maybe I can convince myself that it is a
good idea NOT to print such expressions *except* when they occur as
top-level expressions typed at an interactive command prompt. This
would break little code (though a "cute" debugging feature is lost)
and make most parties happy. Then the silly -k switch can also go.
If I don't convince myself I'll add "pass [expression]" to the
language as the recommended way to suppress the printing.
An intermediate step would be to suppress the non-interactive printing
for function/method calls only, but this seems to have little virtue.
(And thanks for your other remarks and the bug report about "raise
()", Tim!)
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>