merits of Lisp vs Python

Andrea Griffini agriff at tin.it
Sat Dec 9 05:08:34 EST 2006


Alex Mizrahi wrote:

...

> so we can see PyDict access. moreover, it's inlined, since it's very 
> performance-critical function.
> but even inlined PyDict access is not fast at all. ma_lookup is a long and 
> hairy function containing the loop.

I once had a crazy idea about the lookup speed problem;
can't the lookup result be cached in the bytecode ?
I am thinking to something like saving a naked pointer
to the value together with a timestamp of the dictionary.
With timestamp I mean an integer (may be 64 bit) that is
incremented and stamped in the dictionary every time
the dictionary is modified; this counter can be
shared among all dictionaries. The use of a naked pointer
would be IMO safe because to invalidate the object you
would also need to touch the dictionary.

Using this approach the lookup for a constant
string could be

	if (bytecode_timestamp == dict->timestamp)
         {
	   // just use the stored result
         }
         else
         {
            // do standard lookup and store
            // result and dict->timestamp
         }

I'd expect that this would be a big win for a lot of
lookup as the problem with python speed is the *potential*
dynamism... hopefully people don't keep changing what
math.sin is during the execution so the vast majority of
lookups at module level will find the timestamp being valid.
This invalidation is not "optimal" as changing math.sin
would also invalidate any lookup on math, but IMO a lot
of lookups happen in *fixed* dictionaries and the the
overhead of checking the cached result first should be
small. What it would break is code that actually
dynamically changes the string being looked up in the
dictionary in the bytecode, but I hope those places
are few if the exist at all.

Is this worth investigation or it has already
been suggested/tried ?

Andrea



More information about the Python-list mailing list