This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author methane
Recipients josh.r, louielu, methane, r.david.murray, rhettinger, serhiy.storchaka, tim.peters, xiang.zhang
Date 2019-03-12.15:56:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1552406214.04.0.266783321236.issue30040@roundup.psfhosted.org>
In-reply-to
Content
> I don't think this should have been done.  Conceptually, there is no basis for presuming key-sharing for new empty dicts -- you can't know what they would share with.  
This patch essentially undoes the entire reason for having a pre-allocated minsize dict.  If it were deemed to be the norm that applications typically had huge numbers of empty dicts that were never populated, then the correct solution would be a NULL pointer to the table field (as dicts do).

It increases massive NULL checks, and possibly cause bugs.

> FWIW, the macro benchmarks aren't very informative here because they don't exercise much of this code.  I think there is an over-prioritization of small space savings at the expense of the intended use cases for dicts.  This patch just forces every dict that gets used to have to convert back from a key-sharing dict and do a memory allocation and memset(0) in the process.  The whole point of the minsize dict was to avoid that cost in the common case of small dicts (i.e. passing keyword arguments).

Note that there is _PyDict_NewPresized().

When kwargs is empty, this patch increase dict creation speed.
When kwargs is not empty, temporary key-sharing table is not used because we use _PyDict_NewPresized() is used.

$ ./py.edict bm_edict.py --compare-to ./py.master
py.master: ..................... 192 ns +- 7 ns
py.edict: ..................... 175 ns +- 4 ns
Mean +- std dev: [py.master] 192 ns +- 7 ns -> [py.edict] 175 ns +- 4 ns: 1.10x faster (-9%)

py.master: ..................... 269 ns +- 4 ns
py.edict: ..................... 273 ns +- 2 ns
Mean +- std dev: [py.master] 269 ns +- 4 ns -> [py.edict] 273 ns +- 2 ns: 1.02x slower (+2%)

So I don't think net performance of kwargs doesn't get worse.
History
Date User Action Args
2019-03-12 15:56:54methanesetrecipients: + methane, tim.peters, rhettinger, r.david.murray, serhiy.storchaka, josh.r, xiang.zhang, louielu
2019-03-12 15:56:54methanesetmessageid: <1552406214.04.0.266783321236.issue30040@roundup.psfhosted.org>
2019-03-12 15:56:54methanelinkissue30040 messages
2019-03-12 15:56:53methanecreate