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 -- http://mail.python.org/mailman/listinfo/python-list