Repository navigation
[Repo Assist] perf: cache GetParameters/PropertyType/FieldType/EventHandlerType in target-model wrappers - #513
Merged
dsyme merged 2 commits intoMay 1, 2026
Conversation
…target-model wrappers The tx* wrapper functions for TargetTypeDefinition member wrappers (txILConstructorDef, txILMethodDef, txILPropertyDef, txILEventDef, txILFieldDef) previously recomputed type-resolved values on every call: - GetParameters() re-ran Array.map over txILParameter on every call - PropertyType re-ran txILType on every call - GetIndexParameters() re-ran Array.map over txILParameter on every call - EventHandlerType re-ran txILType on every call - FieldType re-ran txILType on every call Since TargetTypeDefinition caches its member wrappers in lazy arrays (ctorDefs, methDefs, fieldDefs, propDefs, eventDefs), the same wrapper objects are reused across calls. Caching these derived values with lazy eliminates redundant type-resolution and array allocation on repeated access — which occurs frequently when the F# compiler type-checks a generative type provider's generated assembly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
dsyme
marked this pull request as ready for review
May 1, 2026 16:24
dsyme
approved these changes
May 1, 2026
4 tasks
dsyme
added a commit
that referenced
this pull request
Jul 29, 2026
…er body (issue #341) (#520) ## Problem Issue #341 reported that generative compilation (`AssemblyCompiler.Compile`) is still very slow for large providers (SwaggerProvider + Stripe schema), even after the memoization work in #443/#457/#471/#493/#497/#502/#509/#513. Profiling the benchmark suite with dotnet-trace showed that with those caches in place, **~80% of `Compile` time was FSharp.Core quotation deserialization** (`PatternsModule.deserialize` → `instMeth` → `GetGenericArguments`/`MakeGenericType`), attributed to the `CodeGenerator` constructor. Root cause: `CodeGenerator` defines ~63 active patterns from quotation literals — `let (|Addition|_|) = (|SpecificCall|_|) <@ (+) @>`, `<@ max @>`, `<@ sqrt @>`, etc. Evaluating a quotation literal deserializes it (reflection-binding every method it mentions), and a `CodeGenerator` is constructed **once per emitted member body**. A provider with 10,000 members therefore deserialized those quotations ~630,000 times. `lessThan` was worse still: it deserialized `<@@ (<) @@>` on every call. ## Fix * New `CodeGenPatterns(convTypeToTgt)` type holding all these patterns as `member val` properties, so they are computed once at construction (a plain property getter would re-evaluate per access). * `AssemblyCompiler.Compile` constructs one instance and passes it to every `CodeGenerator`; the constructor now just re-binds the local active patterns from it, so the large `emitExpr` match code is untouched. * `lessThan` uses a precomputed generic method definition. ## Results Quick benchmark (`benchmarks -- --quick`, ms/iter, before → after): | Scenario | Before | After | Speedup | |---|---|---|---| | Methods 50×20 | 880 | 86 | 10× | | Methods 200×20 | 2893 | 180 | 16× | | Methods 1000×10 | 6892 | 535 | 13× | | Props 500×10 | 8074 | 1259 | 6.4× | | ComplexBody 300×10 | 2528 | 158 | 16× | | Nested 100×4×5 | 1668 | 127 | 13× | End-to-end with the exact repro from #341 (SwaggerProvider built from source against this branch, Stripe `spec3.sdk.json`, `dotnet fsi`): **62–72 s → 19–20 s** wall clock; the remainder is dominated by schema download, OpenApi parsing and fsi startup rather than the TPSDK. Re-profiling after the change confirms the SDK-side deserialization is gone; the remaining `deserialize` samples come from the provider author's own `<@@ ... @@>` literals in `invokeCode` (once per member, inherent to user code). ## Testing * Full test suite passes: 160/160. * Benchmark suite builds and runs (numbers above). * SwaggerProvider builds unmodified against the patched `ProvidedTypes.fs` and the generated Stripe client works (`Stripe.Client()` constructed successfully). Fixes #341 (the remaining slowness reported there after the earlier rounds of caching). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Don Syme <dsyme@github.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 is an automated PR from Repo Assist.
Summary
Caches computed values in the target-model member wrappers (
txILConstructorDef,txILMethodDef,txILPropertyDef,txILEventDef,txILFieldDef) insideTargetTypeDefinitionto avoid repeated type-resolution and array allocations on every call.What was happening
Each wrapper function creates a
new XxxInfo()object expression. Before this change, several frequently-called members recomputed their results from scratch on every access:txILConstructorDefGetParameters()Array.map (txILParameter ...)every calltxILMethodDefGetParameters()Array.map (txILParameter ...)every calltxILPropertyDefPropertyTypetxILTyperesolution every calltxILPropertyDefGetIndexParameters()Array.map (txILParameter ...)every calltxILEventDefEventHandlerTypetxILTyperesolution every calltxILFieldDefFieldTypetxILTyperesolution every callWhy this matters
TargetTypeDefinitionalready caches its member wrapper arrays vialazy(ctorDefs,methDefs,fieldDefs,propDefs,eventDefs). This means the same wrapper objects are reused across calls. Without result caching inside the wrappers, every access toGetParameters(),PropertyType, etc. allocates a new array and re-runs IL type resolution — which the F# compiler does repeatedly during type inference against a generative type provider's generated assembly.Fix
Added
lazybindings before each object expression to cache the computed results:All 157 tests pass.