When deepcopying, don't store immutable objects in the memo dict

[alex]

BPO	12422
Nosy	@cfbolz, @alex
Files	d.diff d.diff d.diff

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2011-06-27.21:22:57.858>
created_at = <Date 2011-06-27.15:29:44.415>
labels = ['library']
title = "When deepcopying, don't store immutable objects in the memo dict"
updated_at = <Date 2011-06-27.21:22:57.856>
user = 'https://github.com/alex'

bugs.python.org fields:

activity = <Date 2011-06-27.21:22:57.856>
actor = 'python-dev'
assignee = 'none'
closed = True
closed_date = <Date 2011-06-27.21:22:57.858>
closer = 'python-dev'
components = ['Library (Lib)']
creation = <Date 2011-06-27.15:29:44.415>
creator = 'alex'
dependencies = []
files = ['22497', '22499', '22500']
hgrepos = []
issue_num = 12422
keywords = ['patch']
message_count = 5.0
messages = ['139300', '139303', '139315', '139322', '139327']
nosy_count = 3.0
nosy_names = ['Carl.Friedrich.Bolz', 'alex', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue12422'
versions = ['Python 2.7', 'Python 3.3', 'Python 3.4']

[alex]

All storing immutable objects in the memo dict does is slow stuff down, due to having a larger hash table, and on some other Python's causing hilarious levels of GC pressure. Using http://paste.pocoo.org/show/421310/ as a benchmark, CPython get's a 2x speedup on the deepcopy portion, and PyPy a 20x. Patch is attached.

[alex]

A slightly cleverer version (or less clever, depending on how you approach the issue) that also works with tuples of immutable content.

[alex]

Switched to using assertIs, as merwok suggested.

[alex]

Amaury points out: this is not strictly about immutable objects, but rather objects who's deepcopy is themselves (identity-wise), in some (rare I think) cases this could provide a slowdown. Specifically a case of [(1, 2, 3)] * 10000 would be slower, because it would review each tuple individually, rather than using the memo'd instance. I suspect this case is not so common (to have the same identity object, who's deepcopy is itself such as a tuple or object with custom __deepcopy__, many times in a deepcopy object graph), but I have no proof of this.

[python-dev]

New changeset e24ad85e9608 by Benjamin Peterson in branch 'default':
don't memoize objects that are their own copies (closes bpo-12422)
http://hg.python.org/cpython/rev/e24ad85e9608