Cache array-like wrapper factories and materialize length lazily#2730
Merged
Conversation
Every conversion of a CLR array/list under LiveView built its wrapper through Activator.CreateInstance(type, args), paying the full reflection binder per creation, and eagerly allocated the length forwarder (ClrFunction + GetSetPropertyDescriptor + property store) that plain length reads never consult (they are served by the ICollection fast path in Get). Resolve a typed ArrayLikeWrapperFactory once per exposed type and create wrappers through it, and materialize the length descriptor on first own-property consultation instead of in the constructor. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jul 22, 2026
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
1 participant
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.
With
ArrayConversiondefaulting toLiveView(#2728), the dominant cost of a CLR collection member read from script became wrapper construction itself (context in #2729). Profiling theinterop-collection-traversalcomparison row shows the conversion path at ~70% of the row, and inside it two avoidable blocks:Activator.CreateInstance(arrayWrapperType, engine, target, type)pays the full reflection binder (DefaultBinder.BindToMethod+RuntimeConstructorInfo.Invoke+ argument marshaling) on every wrapper creation — over half the wrapper-build subtree.ObjectWrapperconstructor eagerly allocates thelengthforwarder (ClrFunction+GetSetPropertyDescriptor+ the_propertiesstore) that plainlengthreads never consult — they are served by theICollectionfast path inGet.Changes
ArrayLikeWrapperFactory(oneActivatorcall per exposed type, ever) and every wrapper creation is a virtual call + direct constructor. The trimming fallback behavior is unchanged: a trimmed constructor caches anullfactory and falls back to the non-genericListWrapperexactly as before.lengthforwarder is materialized lazily on first own-property consultation (GetOwnProperty, theSetmember gate, or an explicit removal). Descriptor shape, configurability, delete semantics and enumeration are unchanged — covered by a new test plus the existing extracted-getter tests.Benchmarks (same machine, adjacent same-base A/B, default job)
InteropWrapperChurnBenchmark:EngineComparisonInteropBenchmark(Jint lane):A single-launch run showed property-access +19% on this branch; a launchCount-5 A/B (both sides) adjudicated it as code-layout bimodality — the five-launch means are statistically identical. The collection-traversal delta was re-confirmed at launchCount-5 (6.044 → 2.302 ms).
Gates: full Jint.Tests (net10.0 + net472), Jint.Tests.PublicInterface, Test262 99,431 passed / 0 failed.
🤖 Generated with Claude Code