Question about dictobject.c:lookdict_string
My question is specifically regarding the transition back from lookdict_string (the initial value) to the general lookdict. Currently, when a string-only dict is trying to look up any non-string, it reverts back to a general lookdict. Wouldn't it be better (especially in the more important case of a string-key-only dict), to revert to the generic lookdict when a non-string is inserted to the dict, rather than when one is being searched? This seems to me as it would shift this (admittedly very slight) performance cost of a type ptr comparison from the read-access, to write-access on all dicts (which means insertions of new keys in non-string-only dicts may pay for another check, or that the lookdict funcptr will be replaced by two funcptrs so that a different insertion func on string-only dicts is used too [was tempted to say vtable here, but that would add another dereference to lookups]). It would also have the slight benefit of speeding up non-string lookups in string-only dicts. This does not seem like a significant issue, but as I know a lot of effort went into optimizing dicts, I was wondering if I am missing something here.
Eyal Lotem wrote:
My question is specifically regarding the transition back from lookdict_string (the initial value) to the general lookdict.
Currently, when a string-only dict is trying to look up any non-string, it reverts back to a general lookdict.
Wouldn't it be better (especially in the more important case of a string-key-only dict), to revert to the generic lookdict when a non-string is inserted to the dict, rather than when one is being searched? [...] This does not seem like a significant issue, but as I know a lot of effort went into optimizing dicts, I was wondering if I am missing something here.
Yes, you are: when doing a lookup with a non-string-key, that key could be an instance of a class that has __hash__ and __eq__ implementations that make the key compare equal to some string that is in the dictionary. So you need to change to lookdict, otherwise that lookup might fail. Cheers, Carl Friedrich Bolz
On 6/11/07, Carl Friedrich Bolz
Eyal Lotem wrote:
My question is specifically regarding the transition back from lookdict_string (the initial value) to the general lookdict.
Currently, when a string-only dict is trying to look up any non-string, it reverts back to a general lookdict.
Wouldn't it be better (especially in the more important case of a string-key-only dict), to revert to the generic lookdict when a non-string is inserted to the dict, rather than when one is being searched? [...] This does not seem like a significant issue, but as I know a lot of effort went into optimizing dicts, I was wondering if I am missing something here.
Yes, you are: when doing a lookup with a non-string-key, that key could be an instance of a class that has __hash__ and __eq__ implementations that make the key compare equal to some string that is in the dictionary. So you need to change to lookdict, otherwise that lookup might fail. Ah, thanks for clarification.
But doesn't it make sense to only revert that single lookup, and not modify the function ptr until the dict contains a non-string? Eyal
participants (2)
-
Carl Friedrich Bolz
-
Eyal Lotem