perf: Add an option to skip OpenAPI schema initialization #5932
+7
−4
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.
This PR introduces a new
skip
field to theopenapi
map in the kustomization file.Problem
When using Kustomize as a library,
Kustomizer.Run
callsopenapi.SetSchema
on every execution. In high-frequency scenarios where the same schema is used repeatedly, this leads to a significant performance bottleneck due to redundant schema compilation.In our use case, we call
Kustomizer.Run
thousands of times. Flame graph analysis showed that schema compilation was a major contributor to the overall execution time.Solution
By setting
openapi.skip
totrue
, users can now bypass the call toopenapi.SetSchema
insideKustomizer.Run
. This allows library consumers to initialize the schema once at application startup and reuse it for all subsequent runs.Example workflow:
openapi.SetSchema(...)
.kustomization.yaml
, add theskip
field:kustomizer.Run()
as usual.Result
This change dramatically improves performance in our scenario, reducing the total processing time from 30 minutes to 9 minutes.
Next Steps and Design Alternatives
I've submitted this patch as a minimal implementation to start a discussion and validate the approach. I'm keen to hear your feedback and I'm ready to make adjustments.
Here are a few alternatives I've considered:
kustomization.yaml
format, we could add a new field directly to theKustomizer
struct (e.g.,Kustomizer.SkipOpenAPISchema
). This would make the feature available only when Kustomize is used as a library, which is the primary use case for this optimization. I'm happy to implement it this way if you prefer.skip
is a placeholder. A more descriptive name likeusePreconfiguredSchema
orbuilt-in
might be better. I don't have a strong preference and am open to suggestions.My main goal is to get early feedback on whether this direction for performance improvement is welcome before investing more time.