[issue29019] dict.fromkeys overallocates when given a sparse dict
New submission from Rasmus Villemoes: Somewhat related to #23971, but with the opposite sign: Using Py_SIZE on a PyDictObject gives the ma_fill member in 2.7 (and until 3.2 AFAICT), not the ma_used member. So calling dict.fromkeys(d) overallocates significantly if a lot of elements have been deleted from d. The fix is trivial, though one could of course avoid the function call and do a cast. Not sure this qualifies for 2.7, though. -- components: Interpreter Core files: fromkeys.patch keywords: patch messages: 283654 nosy: villemoes priority: normal severity: normal status: open title: dict.fromkeys overallocates when given a sparse dict type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file45973/fromkeys.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28607] C implementation of parts of copy.deepcopy
Rasmus Villemoes added the comment: New version, addressing (hopefully) all review comments. -- Added file: http://bugs.python.org/file45400/deepcopy.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28607> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28607] C implementation of parts of copy.deepcopy
New submission from Rasmus Villemoes: This is mostly an RFC patch. It compiles and passes the test suite. A somewhat silly microbenchmark such as ./python -m timeit -s 'import copy; x = dict([(str(x), x) for x in range(1)]);' 'copy.deepcopy(x)' runs about 30x faster. In the (2.7 only) application which motivated this, the part of its initialization that does a lot of deepcopying drops from 11s to 3s. That it's so much less is presumably because the application holds on to the deepcopies, so there's much more allocation going on than in the microbenchmark, but I haven't investigated thoroughly. In any case, a 3.5x speedup is also nice. -- components: Library (Lib) files: deepcopy.patch keywords: patch messages: 280032 nosy: villemoes priority: normal severity: normal status: open title: C implementation of parts of copy.deepcopy type: performance versions: Python 3.7 Added file: http://bugs.python.org/file45344/deepcopy.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28607> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
