Attribute cache silently disabled after 1000 class edit, leading to poor performance
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Bug report
Bug description:
After the changes from https://github.com/python/cpython/pull/114900 modifying a class more than 1000 times causes the attribute cache to be permanently disabled for that class. This was done to solve a crash when a class is modified more than 2**32 times ( https://github.com/python/cpython/issues/113462 )
It seems this number (1000) is too low for some real case applications.
I initially observed this as a ~50% performance regression in ERP5 performance tests when updating from python3.11 to python3.13. ERP5 is an application where classes are generated dynamically based on some configuration and some classes are modified more than 1000 times in the "normal" generation process.
This seems to also affect odoo, another ERP application, for this they resorted to using ctypes to reset the class version attribute ( https://github.com/odoo/odoo/pull/275640 )
My suggestion would be to use a much higher number before disabling the cache, 1000 is low.
CPython versions tested on:
3.13
Operating systems tested on:
Linux
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing CPython pull request 114900 and issue 113462, then trace how the attribute cache is disabled after repeated class modifications. Use the ERP5 and Odoo cases described in the issue as performance scenarios. Done means avoiding the reported regression while still addressing the crash scenario from issue 113462.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100