Activity

1. perrinjerome

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Aug 25, 2026
2. aisk

   added

   performancePerformance or resource usagePerformance or resource usage

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   on Aug 25, 2026
3. StanFromIreland commented on Aug 25, 2026

   

   StanFromIreland

   on Aug 25, 2026

   Member

   More actions

   CC @markshannon and @Fidget-Spinner
4. markshannon commented on Aug 26, 2026

   

   markshannon

   on Aug 26, 2026

   Member

   More actions

   The limit (1000) was chosen quite arbitrarily.
   What limit would be sufficient for your use case?
5. perrinjerome commented on Aug 26, 2026

   

   perrinjerome

   on Aug 26, 2026

   Last edited by perrinjerome

   ContributorAuthor

   More actions

   Thank you. I tried running a patched interpreter with 10 000 instead of 1000 and it was enough for my case, but I suspect there can even be cases with more than 10 000 edits.

   If the original problem starts with 2**31, maybe the limit can be set to something much higher, would something like 2**30 be possible ?
6. markshannon commented on Aug 26, 2026

   

   markshannon

   on Aug 26, 2026

   Member

   More actions

   maybe the limit can be set to something much higher, would something like 2**30

   The sum of all modifications for all classes should not reach 2**32.
   Allowing 2**30 for a single class could be broken by 4 classes.

   I understand why reloading a model would make many changes, but why the interleaved attribute loads?
   Typically, how many loads occur between each change to the class?

   I'm actually reluctant to increase the number much, for internal reasons to do with detecting the difference between cache misses due to polymorphism vs stale version numbers.

   What we could do, is add a counter that tracks the number of times we want to update the version number, and only update the version number when that reaches the number of versions used. Instead of N changes before the cache stopped working it would be N*(N-1)/2 changes.

   That should allow about 500k version changes, for N=1000, at the cost of slower look ups for the first several lookups after a change to the class.
   For a class that makes 1000 changes, it would take about 50 lookups before the cache kicks in after the 1000th change/load pair.
7. perrinjerome commented on Aug 28, 2026

   

   perrinjerome

   on Aug 28, 2026

   Last edited by perrinjerome

   ContributorAuthor

   More actions

   I understand why reloading a model would make many changes, but why the interleaved attribute loads?
   Typically, how many loads occur between each change to the class?

   The simplified pattern is something like this:

   for attribute_name, attribute in get_dynamic_attributes():
     if not hasattr(cls, attribute_name):
       setattr(cls, attribute_name, attribute)

   so each hasattr performs a load and we have a load directly after each class modification.

   I realize today I can probably just rewrite this pattern to:

   class_attributes = set(dir(cls))
   for method_name, method in get_dynamic_attributes():
     if attribute_name not in class_attributes:
       setattr(cls, attribute_name, attribute)

   with this approach, there is no load so the version is not increased. Building the class would also probably be slightly faster because it would not rebuild the cache in each loop, so I feel it's generally good if I can change my code like this. Thank you for helping me realize this, I will try this in the next days.

   Still, from this experience, I feel this change of disabling the cache after 1000 class modifications is not ideal, for users it manifests as a performance degradation and the root cause is hard to find. I still have the intuition that it could be increased a bit.