[Types-sig] Low-hanging fruit: recognizing builtins

[Guido van Rossum]

> How about also adding caching of globals
> which are not modified within the module in locals ? This
> would save another cylce or two. The caching would have
> to take place during function creation time. I'm currently doing
> this by hand which results in ugly code... :-( but faster execution
> :-)

Indeed -- the same analysis I was proposing would also support this.
However there's a common pattern that can be a problem here (and isn't
a problem for the built-in functions analysis): modules often have a
few global variables that are initialized only once in the module, but
are clearly (e.g. through comments) intended to be modified by using
modules.  Examples: default files, debug levels, and the like.  I'm
not sure how to detect this pattern reliably, unless you decide to
cache only functions, classes, and imported modules.

> Note that interning the builtins as byte codes could be
> a security risk when executing in a restricted environment,
> though. Some builtin operations might not be allowed and but would
> still be available via bytecode.

Of course a restricted environment should not accept arbitrary
bytecode!  Also you could simply not define bytecodes for
security-sensitive built-ins; the only ones I cna think of right now
are __import__() and open(), which I already mentioned as exceptions.

Note that a bunch of built-in constants can also be optimized using
this same mechanism: None and perhaps exception names.  I'm not sure
that exception names are worth it though; they don't tend to be
touched in inner loops where performance gains are made.  But None is
definitely worth its own 1-byte opcode.

--Guido van Rossum (home page: http://www.python.org/~guido/)