[Patches] [ python-Patches-711722 ] Cache lookup of __builtins__

[SourceForge.net]

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: Raymond Hettinger (rhettinger)
Date: 2003-03-30 16:59

Message:
Logged In: YES 
user_id=80475

I see.

Would this patch be acceptable as a -OO option or should 
I drop it?

Also, the same question applies to a tiny patch converting 
  LOAD_GLOBAL "None"   -->   LOAD_CONST Py_None


----------------------------------------------------------------------

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