You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lazily constructs generated APIOperation instances when they are first accessed.
This is PR 1 of 2. The follow-up PR partitions generated schemas and model stubs.
Why this comes first
Schema partitioning only helps if importing a client does not access every operation schema. Eager operation construction would resolve those schemas during import and load most or all schema partitions immediately.
This change stores lightweight operation metadata instead. When an operation is first used, models.__getattr__ constructs and caches its APIOperation. This allows the follow-up partitioning change to load only the schema partitions needed by the operations and models being used.
Changes
Store operation schema, error, and authentication IDs as metadata.
Construct operations through models.__getattr__.
Cache operation instances after first access.
Resolve operations from models when clients invoke them.
Preserve existing operation exports and identity.
EC2 benchmark
Measured on x86 with 20 runs, three warmups, and five allocation runs.
Metric
Eager
Lazy
Change
Generated source
6.18 MiB
6.19 MiB
+0.2%
Client import
184.87 ms
182.81 ms
-1.1%
Process time
296.02 ms
294.08 ms
-0.7%
Peak RSS
55.86 MiB
53.73 MiB
-3.8%
Peak Python allocation
22.72 MiB
21.95 MiB
-3.4%
First operation access
0.001 ms
0.011 ms
+0.010 ms
Remaining work
PR 2 will:
Partition generated schemas for large services.
Partition models.pyi to improve static-analysis performance.
Preserve stable schemas.py and models.pyi facades.
Keep recursive schema components together.
Continue producing single files for smaller services.
The combined prototype using 25-shape schema partitions reduced EC2 client import by 10.8%, process time by 9.2%, peak RSS by 15.4%, and peak Python allocation by 29.5% compared with the eager, unpartitioned baseline.
Runtime model classes will not be partitioned because they are already constructed lazily.
Compatibility
Generated operation names remain available from models, and repeated access returns the same cached instance.
This PR makes the Java generator defer APIOperation construction until first access, preparing generated clients for schema partitioning in the follow-up PR.
Changes:
Replace eager operation instances with metadata and lazy construction through models.__getattr__.
Resolve operations when client methods run, while retaining operation exports and caching.
Regenerate nine client/model pairs and add generation assertions.
The added source-string assertions do not verify runtime laziness or cached identity, so regressions in these guarantees could pass unnoticed. Add a regression test in a fresh process that imports a generated client, confirms operation constants are absent from vars(models), then accesses one operation through both attribute access and from ...models import ..., asserting the same cached instance while unrelated operations remain unloaded.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue #, if available:
#797
Description
Lazily constructs generated
APIOperationinstances when they are first accessed.This is PR 1 of 2. The follow-up PR partitions generated schemas and model stubs.
Why this comes first
Schema partitioning only helps if importing a client does not access every operation schema. Eager operation construction would resolve those schemas during import and load most or all schema partitions immediately.
This change stores lightweight operation metadata instead. When an operation is first used,
models.__getattr__constructs and caches itsAPIOperation. This allows the follow-up partitioning change to load only the schema partitions needed by the operations and models being used.Changes
models.__getattr__.modelswhen clients invoke them.EC2 benchmark
Measured on x86 with 20 runs, three warmups, and five allocation runs.
Remaining work
PR 2 will:
models.pyito improve static-analysis performance.schemas.pyandmodels.pyifacades.The combined prototype using 25-shape schema partitions reduced EC2 client import by 10.8%, process time by 9.2%, peak RSS by 15.4%, and peak Python allocation by 29.5% compared with the eager, unpartitioned baseline.
Runtime model classes will not be partitioned because they are already constructed lazily.
Compatibility
Generated operation names remain available from
models, and repeated access returns the same cached instance.