Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce the number of materialized instance __dict__s #106485

Closed
markshannon opened this issue Jul 6, 2023 · 4 comments
Closed

Reduce the number of materialized instance __dict__s #106485

markshannon opened this issue Jul 6, 2023 · 4 comments
Labels
performance Performance or resource usage

Comments

@markshannon
Copy link
Member

markshannon commented Jul 6, 2023

Accessing the __dict__ attribute of an object causes the dictionary to be materialized.
This has a negative impact on performance.
We should provide means to access the __dict__ without forcing materialization, which can be used in copy, pickle and any third party code that chooses to.

I propose two new methods on object:

  • __dict_copy__(self), which will be equivalent to self.__dict__.copy(), but without materializing the dictionary of objects with virtual dictionaries.
  • __dict_update__(self, arg), which will be equivalent to self.__dict__.update(arg), but without materializing the dictionary of objects with virtual dictionaries.

Linked PRs

@brandtbucher
Copy link
Member

I opened a draft PR for an alternate approach, which aggressively "un-materializes" __dict__s in LOAD_ATTR_WITH_HINT.

@kumaraditya303
Copy link
Contributor

This change seems to be causing crashes on buildbots. See https://buildbot.python.org/all/#/builders/123/builds/813 as example.

@markshannon
Copy link
Member Author

Two more things to fix:

  • Instances created by copy.deepcopy do not get their __dict__s dematerialized.
  • We shouldn't be creating dictionaries in _PyObjectDict_SetItem for objects with managed __dict__s if the key is in the shared keys.

@hugovk
Copy link
Member

hugovk commented Nov 10, 2023

Is there more to do here, or can we close this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Performance or resource usage
Projects
None yet
Development

No branches or pull requests

4 participants