[Patches] [ python-Patches-711722 ] Cache lookup of __builtins__
SourceForge.net
noreply@sourceforge.net
Sun, 30 Mar 2003 11:02:39 -0800
Patches item #711722, was opened at 2003-03-29 01:47
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711722&group_id=5470
Category: Core (C code)
Group: Python 2.3
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cache lookup of __builtins__
Initial Comment:
Rather than perform a bytecode optimization of
LOAD_GLOBALS, takes an alternative approach of
caching the lookup of builtins.
To be safe, it checks the cache only after trying a
lookup in globals(). I can think of only one way to
break this approach: run the function accessing a
builtin, then poke a new value into the builtins
module, and then re-run the function:
def f(x):
return oct(x)
print f(20)
__builtins__.oct = hex
print f(20) # doesn't notice new def of oct()
The gives about a 2% speed-up to average programs,
0% to programs that don't use builtins, and higher
percentages to those with heavier use of builtins. The
speedup is limited by 1) having to still check globals
and 2) the relative insignificance of builtin access time
in most programs. Still, it pretty much solves the
problem of access time for builtins.
----------------------------------------------------------------------
>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-30 14:02
Message:
Logged In: YES
user_id=6380
That prohibition isn't agreed yet, and would be new. Since
this *is* a change in existing semantics and rule, there
would have to be a period where the old semantics were
maintained but a warning was given about violating the new
rule. Your patch doesn't do any of that.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-03-29 12:11
Message:
Logged In: YES
user_id=80475
Arghh, I don't see what the problem is. The co_names
cache variable is private and not part of the public
interface for code objects. The only way to see a change in
behavior is for a program to violate the prohibition of
sticking a name in another module's globals that affects a
builtin (and, even then, it would have to occur between
calls the the function). Normal shadowing (using globals)
would continue to work just fine.
While it gives only a minor timing gain, the big win would
be removing the incentive to create python code like this:
def f(x, y, int=int, True=True, chr=chr):
. . .
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-29 06:37
Message:
Logged In: YES
user_id=6380
-1. It changes semantics in an ad-hoc way.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=711722&group_id=5470