INADA Naoki added the comment: > 0 (128, 60) > 1 (128, 60) > 2 (128, 60) > 3 (128, 60) > 4 (128, 60) > 5 (128, 60)
Minimum dict keysize is 8, and it's capacity is 5. > 6 (196, 196) Dict is resized. And since __dict__.update() caused the resizing, both are normal (combined) dict. > 7 (196, 196) > 8 (196, 344) dict.update() cause faster increasing keysize. Adding to dict cause resizing when number of items reaches 2/3 of keysize. On the other hand, dict.update() targets 1/2 of keysize is filled. In this case, keysize is 16 and 16 * 2 // 3 = 10. Since 8 < 10, adding item to key doesn't increase it's size. Since 8 >= (16 / 2), dict.update() creates dict having keysize == 32. (note: My patch in http://bugs.python.org/issue28147 changes >= to >. So keysize == 16 when number of items == 8). But, while checking this, I found another bug in dict_merge. /* Do one big resize at the start, rather than * incrementally resizing as we insert new items. Expect * that there will be no (or few) overlapping keys. */ if (mp->ma_keys->dk_usable * 3 < other->ma_used * 2) if (dictresize(mp, (mp->ma_used + other->ma_used)*2) != 0) return -1; dk_usable means "how many new items can be inserted without resizing". So this if statement should be: if (mp->ma_keys->dk_usable < other->ma_used) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28509> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
