[Skip Montanaro, on
def mylen(s):
return len(s)
]
> Yeah, it's
>
> TRACK_GLOBAL 'len'
> LOAD_FAST <len>
> LOAD_FAST <s>
> CALL_FUNCTION 1
> UNTRACK_GLOBAL 'len'
> RETURN_VALUE
>
> or something similar. (Stuff in <...> represent array indexes.)
>
> My scheme makes update of my local copy of __builtins__.len
Who is the "me" in "my"? That is, is "my local copy" attached to the frame,
or to the function object, or to the module globals, or ...? Since it's
accessed via LOAD_FAST, I'm assuming it's attached to the frame object.
> the responsibility of the guy who changes the global copy.
Also in my variant of Guido's proposal (and the value of len is cached in
the module dict there, which tracks all changes to the builtins as they
occur).
> Most of the time this never changes,
Right.
> so as the number of accesses to len increase, the average time per
> lookup approaches that of a simple LOAD_FAST.
You mean number of accesses to len per function call, I think. If I do
for i in xrange(1000000):
print mylen("abc")
I'm going to do a TRACK_GLOBAL and UNTRACK_GLOBAL thingie too for each
LOAD_FAST of len, and then the average time per len lookup really has to
count the average time for those guys too.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4