markjm opened a new pull request, #3377:
URL: https://github.com/apache/thrift/pull/3377

   In this area of code, there already exists an optimization where we skip 
calling `klass(**kwargs)` on the top-level struct and instead init an empty 
object then PyObject_SetAttr the properties onto it.

This was done because 
Python's keyword argument matching is O(n) string comparisons per argument, 
making this expensive for structs with many fields.
   
   However, nested structs which are decoded within the C extension did not get 
this same optimization, causing them to go through the slow class 
initialization path.
   
   In this change, for mutable nested structs, we create the instance up front 
with a no-arg constructor (klass()) and set decoded fields directly via 
PyObject_SetAttr (the same way we fast-path the top-level struct).
   
   Immutable structs (TFrozenBase subclasses) continue to use the kwargs path 
since their generated __setattr__ blocks attribute mutation.
   
   Immutability is detected via PyObject_IsSubclass against TFrozenBase, with 
the class reference cached in a function-local static.
   
   Benchmarks show up to 3.6x speedup for deeply nested struct hierarchies, 
with no impact on flat structs. I had Claude generate me some benchmarks to 
showcase performance in different nested scenarios.

Note the test change. I 
asked about potentially changing this to look more like what the codegen 
produces here https://github.com/apache/thrift/pull/3349/changes#r3026288637. 
Currently, this fails because its not marked as frozen but has a erroring 
setattr
   
   - [ ] Did you create an [Apache 
Jira](https://issues.apache.org/jira/projects/THRIFT/issues/) ticket?  
([Request account here](https://selfserve.apache.org/jira-account.html), not 
required for trivial changes)
   - [ ] If a ticket exists: Does your pull request title follow the pattern 
"THRIFT-NNNN: describe my issue"?
   > can make a ticket if desired
   - [x] Did you squash your changes to a single commit?  (not required, but 
preferred)
   - [x] Did you do your best to avoid breaking changes?  If one was needed, 
did you label the Jira ticket with "Breaking-Change"?
   - [n/a] If your change does not involve any code, include `[skip ci]` 
anywhere in the commit message to free up build resources.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to