Fast Dictionary Access

Carl Banks pavlovevidence at gmail.com
Sun Jun 28 05:57:50 EDT 2009


On Jun 27, 4:40 am, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
> Thomas Lehmann <Iris-und-Thomas-Lehm... at T-Online.de> wrote:
> > Hi!
>
> > In C++, programming STL you will use the insert method which always
> > provides a position and a flag which indicates whether the position
> > results from a new insertion or an exisiting element. Idea is to have
> > one search only.
>
> ><code>
> > if  data.has_key(key):
> >    value = data[key]
> ></code>
>
> > But this does mean (does it?) that the dictionary is searched two
> > times! If so, can somebody show me how to do this in one step?
>
> That code actually does 3 dictionary lookups and creates a temporary
> object: the first lookup is to find the 'has_key' method, then it has to
> bind the method to data which involves creating a 'built-in method' object
> and then it calls it. Only then do you get the two lookups you expected.
>
> Replacing your code with:
>
>    if key in data: value = data[key]
>
> reduces the overhead to two dictionary lookups, no temporary objects or
> function calls.
>
> The suggested alternative:
>
>    value = data.get(key, None)
>
> also has two dictionary lookups: one to find the 'get' method and one to
> find the key, but as in the first case it also has the overhead of binding
> the method and then calling it.
>
> In other words the get method is often the clearest (and therefore best)
> way to write the code, but if performance matters do a check using the 'in'
> operator (or if you know the key lookup will fail only very rarely consider
> using try..except).

It's not that simple.  Attribute lookups are fast because the keys are
interned strings.  However, the key lookup in the data object might be
an object where hash and compare operations are much slower.

So it's not valid in general to equate the two lookups.  Unless you
know that your dict keys are going to be really fast like interned
strings it makes sense to minimize dict lookups.


Carl Banks



More information about the Python-list mailing list