On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote: > On 24 May 2015 at 19:44, Mark Shannon <mark at hotpy.org> wrote: >> On 24/05/15 10:35, Nick Coghlan wrote: >>> If we leave __definition_order__ out for the time being then, for the >>> vast majority of code, the fact that the ephemeral namespace used to >>> evaluate the class body switched from being a basic dictionary to an >>> ordered one would be a hidden implementation detail, rather than >>> making all type objects a little bigger.
>> and a little slower. > The runtime namespace used to store the class attributes is remaining > a plain dict object regardless, Lookup isn't any slower in the ordereddict. Inserts are slower -- and those would happen in the ordereddict, as the type object is being defined. Note that since we're talking about the type objects, rather than the instances, most* long-running code won't care, but it will hurt startup time. *code which creates lots of throwaway classes is obviously an exception. FWIW, much of the extra per-insert cost is driven by either the need to keep deletion O(1) or the desire to keep the C layout binary compatible. A different layout (with its own lookdict) could optimize for the insert-each-value-once case, or even for small dicts (e.g., keyword dicts). I could imagine this producing a speedup, with the ordering being just a side benefit. It is too late to use such a new layout by default in 3.5, but we should be careful not to close it off. (That said, I don't think __definition_order__ would actually close it off, though it might start to look like a wart.) -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
