Title: functools.cached_property possibly disables key-sharing instance dictionaries
Type: performance Stage: resolved
Components: Documentation Versions: Python 3.10, Python 3.9
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Yonatan Goldschmidt, docs@python, miss-islington, rhettinger
Priority: normal Keywords: patch

Created on 2020-10-23 14:51 by Yonatan Goldschmidt, last changed 2020-10-25 02:00 by rhettinger. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 22930 merged rhettinger, 2020-10-23 23:11
PR 22955 merged miss-islington, 2020-10-25 01:17
Messages (4)
msg379439 - (view) Author: Yonatan Goldschmidt (Yonatan Goldschmidt) * Date: 2020-10-23 14:51
Key-sharing dictionaries, defined by, require that any resizing of the shared dictionary keys will happen before a second instance of the class is created.

cached_property inserts its resolved result into the instance dict after it is called. This is likely to happen *after* a second instance has been created, and it is also likely to cause a resize of the dict, as demonstrated by this snippet:

    from functools import cached_property
    import sys

    def dict_size(o):
        return sys.getsizeof(o.__dict__)

    class X:
        def __init__(self):
            self.a = 1
            self.b = 2
            self.c = 3
            self.d = 4
            self.e = 5

        def f(self):
            return id(self)

    x1 = X()
    x2 = X()




    x3 = X()

Essentially it means that types using cached_property are less likely to enjoy the benefits of shared keys. It may also incur a certain performance hit, because a resize + unshare will happen every time.

A simple way I've thought of to let cached_property play more nicely with shared keys, is to first create a single object of the class, and set the cached_property attribute to some value (so the key is added to the shared dict). In the snippet above, if you add "x0 = X(); x0.f = None" before creating x1 and x2, you'll see that the cached_property resolving does not unshare the dicts.

But I wonder if there's a way to do so without requiring user code changes.
msg379479 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-10-23 21:41
> Essentially it means that types using cached_property are less
> likely to enjoy the benefits of shared keys.

I don't think anything can be done about it.  @cached_property and key-sharing dicts are intrinsically at odds with one another.  Likewise, @cached_property doesn't work with classes that define __slots__.

FWIW, there is an alternative that works with both key-sharing dicts and __slots__.  You can stack property() on top of functools.cache():

    class A:
        def __init__(self, x):
                self.x = x

        def square(self):
                return self.x ** 2

    >>> a = A(10)
    >>> a.square
    >>> b = A(11)
    >>> b.square
    >>> a.square
    >>> b.square
msg379552 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-10-25 01:17
New changeset 48be6b1ef7a6201e13c87a317361cdb60bd5faa8 by Raymond Hettinger in branch 'master':
bpo-42127:  Document effect of cached_property on key-sharing dictionaries (GH-22930)
msg379553 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-10-25 02:00
New changeset 427cb0aa78813b89a3f100073bf7d70a53510f57 by Miss Skeleton (bot) in branch '3.9':
bpo-42127:  Document effect of cached_property on key-sharing dictionaries (GH-22930) (GH-22955)
Date User Action Args
2020-10-25 02:00:22rhettingersetmessages: + msg379553
2020-10-25 01:18:19rhettingersetstatus: open -> closed
stage: patch review -> resolved
resolution: fixed
versions: + Python 3.9
2020-10-25 01:17:30miss-islingtonsetnosy: + miss-islington
pull_requests: + pull_request21873
2020-10-25 01:17:25rhettingersetmessages: + msg379552
2020-10-23 23:12:21rhettingersetassignee: docs@python

components: + Documentation, - Library (Lib)
nosy: + docs@python
2020-10-23 23:11:44rhettingersetkeywords: + patch
stage: patch review
pull_requests: + pull_request21852
2020-10-23 21:41:48rhettingersetnosy: + rhettinger
messages: + msg379479
2020-10-23 14:51:35Yonatan Goldschmidtcreate