Allow monomorphization for reducers and more

[lisandroct]

Description of Changes

This PR updates the C# bindings so generated module exports can dispatch directly to statically-known generic reducer, procedure, HTTP handler, view, and anonymous-view entrypoints when building with Native AOT-LLVM.

The runtime now keeps generic static caches for generated dispatchers and exposes generic call paths that avoid relying only on indexed interface collections. The generated FFI forwarding methods switch on the host-provided function/view id and call the matching generic runtime entrypoint, while preserving the existing id-based fallback path.

The previous exported code always used non-generic runtime methods such as Module.__call_reducer__(id, ...), which then indexed into an IReducer list and invoked through the interface. That shape hides the concrete generated reducer/handler/view type from the AOT compiler at the call site.

The generated exports now switch on the function id in generated code and call generic runtime methods such as Module.__call_reducer__<SomeReducer>(...). Because the concrete generated type is present as a generic type argument, NativeAOT can compile a specialized instantiation for that reducer/handler/view. In practice, this gives the AOT compiler a monomorphic call path: it can see the exact dispatcher type, use the static generic cache for that type, and avoid part of the dynamic interface/list dispatch shape that was previously required.

All of this gives extra optimization opportunities in AOT output because the compiler no longer has to treat every reducer invocation as the same opaque interface call.

UPDATE AFTER REVIEW

The important change is that the generic type argument now exists at the actual dispatch site. For example, instead of exporting a method that calls a shared runtime method like:

Module.__call_reducer__(id, ...);

which then indexes into a runtime collection and invokes through IReducer, generated code now emits a switch that calls the concrete generated reducer path directly:

id switch
{
    0 => SomeReducer.Invoke(...),
    1 => OtherReducer.Invoke(...),
    ...
}

The same shape is used for procedures, HTTP handlers, views, and anonymous views. And now it was verified that NativeAOT can take advantage of this and the optimization is real. The previous version still routed through shared generic runtime helpers in a way that did not give NativeAOT a fully concrete call path at the final invocation point. Now the compiler has a monomorphic call path and can specialize the code for that exact generated type, avoid the indexed interface-dispatch shape, and inline through the generated static call path when profitable.

I also considered the extra complexity of keeping the old system around for .NET 8 JIT and decided to simplify the codebase and unify both paths. Now .NET 8 JIT also uses this new path. I benchmarked it against master and the performance is basically flat (if not marginally faster) so there was no reason to keep the old form.

API and ABI breaking changes

The change is internal to C# generated code and runtime dispatch behavior.

Rollback safety impact

n/a

Expected complexity level and risk

3

The main risk is that generated dispatch ids must stay aligned with registration order for reducers, procedures, HTTP handlers, named views, and anonymous views. The implementation preserves fallback id-based dispatch, but it touches the C# module FFI path used by NativeAOT/.NET 10 builds, so reviewers should pay close attention to ordering and parity across all generated dispatcher categories.

Testing

• Ran tests and they're all passing
• Ran targeted C# NativeAOT benchmark comparisons against master
• Repeated benchmark runs to estimate noise/spread

Benchmark Results

All of the text below was AI generated summarizing the benchmark results

Benchmarks were run through the existing harness using C# stdb_module/csharp NativeAOT/.NET 10 module builds.

Each row below reports the median across three runs per branch. The range column is the min/max spread across those three runs, so it gives a rough estimate of run-to-run noise.

Benchmark	master median, range	PR median, range	PR vs master
large args 64KiB	43.768 us, 8.1%	44.100 us, 2.5%	+0.8%
print_bulk lines=1	7.155 us, 22.4%	6.902 us, 9.2%	-3.5%
print_bulk lines=100	60.714 us, 7.1%	57.402 us, 5.1%	-5.5%
print_bulk lines=1000	521.942 us, 8.3%	508.555 us, 4.6%	-2.6%
circles load=10	33.612 ms, 2.3%	33.767 ms, 0.5%	+0.5%
circles load=100	33.789 ms, 2.8%	33.733 ms, 2.7%	-0.2%
ia_loop load=10	10.550 ms, 5.1%	10.529 ms, 1.3%	-0.2%
ia_loop load=100	26.880 ms, 5.1%	26.903 ms, 3.8%	+0.1%
filter string index	44.079 us, 3.5%	44.228 us, 1.9%	+0.3%
filter u64 index	20.212 us, 3.0%	20.309 us, 2.7%	+0.5%
insert u32/u64/str unique	266.848 us, 4.1%	265.643 us, 5.2%	-0.5%
insert u32/u64/str btree	390.298 us, 0.6%	364.261 us, 4.4%	-6.7%
iterate u32/u64/str	44.058 us, 1.5%	44.148 us, 3.3%	+0.2%
insert u32/u64/u64 unique	167.317 us, 6.9%	180.238 us, 5.7%	+7.7%
insert u32/u64/u64 btree	258.715 us, 7.1%	258.304 us, 6.8%	-0.2%
iterate u32/u64/u64	14.932 us, 3.4%	14.979 us, 2.0%	+0.3%

Overall, the PR appears to reduce spread in most of the reducer-heavy special benchmarks. The clearest improvements are:

• print_bulk lines=100: about 5.5% faster
• print_bulk lines=1000: about 2.6% faster
• insert u32/u64/str btree: about 6.7% faster
• print_bulk lines=1: about 3.5% faster, but master had very high spread on this benchmark

Most game, filter, and iterate workloads are effectively flat. These are dominated more by database/query work than by reducer dispatch overhead.

The main negative result in the three-run aggregate was insert u32/u64/u64 unique, which showed +7.7%. I investigated it separately with five focused runs of only that benchmark:

Set	master	PR	Delta
focused median	164.408 us	168.442 us	+2.5%
focused mean	166.759 us	168.588 us	+1.1%
run spread	6.1%	1.5%

The focused rerun does not confirm a meaningful regression. The best estimate is roughly flat, possibly +1-2.5%, while master’s own focused run spread was about 6.1%.

UPDATED BENCHMARKS AFTER REVIEW

Benchmarks were rerun after the review changes using the existing harness.

The NativeAOT numbers below compare master against this PR with .NET 10 AOT builds. Each row reports the median across repeated runs. The range column is the min/max spread across those runs, so it is a rough noise estimate.

Benchmark	master .NET 10 AOT median, range	PR .NET 10 AOT median, range	PR vs master
large args 64KiB	45.030 us, 3.0%	45.970 us, 4.0%	+2.1%
print_bulk lines=1	7.740 us, 4.6%	7.743 us, 4.0%	+0.0%
print_bulk lines=100	67.027 us, 4.0%	67.650 us, 2.8%	+0.9%
print_bulk lines=1000	571.038 us, 2.5%	584.114 us, 3.3%	+2.3%
circles load=10	35.353 ms, 1.9%	34.112 ms, 3.1%	-3.5%
circles load=100	35.163 ms, 3.3%	33.919 ms, 3.1%	-3.5%
ia_loop load=10	10.993 ms, 1.9%	10.660 ms, 3.3%	-3.0%
ia_loop load=100	28.701 ms, 4.4%	27.503 ms, 2.9%	-4.2%
filter string index	47.161 us, 3.0%	47.394 us, 1.2%	+0.5%
filter u64 index	23.866 us, 2.5%	21.674 us, 2.5%	-9.2%
insert u32/u64/str unique	281.629 us, 3.9%	263.539 us, 1.8%	-6.4%
insert u32/u64/str btree	410.007 us, 5.0%	362.381 us, 2.0%	-11.6%
iterate u32/u64/str	46.339 us, 3.6%	44.413 us, 1.7%	-4.2%
insert u32/u64/u64 unique	185.467 us, 4.0%	166.006 us, 1.5%	-10.5%
insert u32/u64/u64 btree	268.584 us, 4.6%	247.646 us, 0.8%	-7.8%
iterate u32/u64/u64	16.668 us, 4.3%	15.355 us, 1.3%	-7.9%

After the review changes, the NativeAOT result is materially better than the original benchmark set, which is what I was expecting originally. The small reducer-only print_bulk benchmarks are roughly flat to slightly slower, but the database-heavy workloads improve consistently. The clearest wins are:

• insert u32/u64/str btree: about 11.6% faster
• insert u32/u64/u64 unique: about 10.5% faster
• filter u64 index: about 9.2% faster
• iterate u32/u64/u64: about 7.9% faster
• insert u32/u64/u64 btree: about 7.8% faster
• insert u32/u64/str unique: about 6.4% faster

I also benchmarked .NET 8 non-AOT builds against master, since the reviewed implementation now uses the same generated direct-dispatch path for both AOT and non-AOT builds.

Benchmark	master .NET 8 JIT median, range	PR .NET 8 JIT median, range	PR vs master
large args 64KiB	521.910 us, 0.3%	521.596 us, 0.4%	-0.1%
print_bulk lines=1	18.917 us, 0.4%	19.384 us, 2.8%	+2.5%
print_bulk lines=100	308.638 us, 0.4%	308.916 us, 0.4%	+0.1%
print_bulk lines=1000	2.924 ms, 0.3%	2.930 ms, 0.9%	+0.2%
circles load=10	794.400 ms, 1.2%	776.488 ms, 0.8%	-2.3%
circles load=100	790.261 ms, 0.8%	776.466 ms, 0.2%	-1.7%
ia_loop load=10	50.046 ms, 0.7%	49.618 ms, 0.5%	-0.9%
ia_loop load=100	131.112 ms, 1.3%	130.555 ms, 0.3%	-0.4%
filter string index	523.986 us, 1.7%	525.000 us, 0.7%	+0.2%
filter u64 index	277.269 us, 0.9%	273.111 us, 0.8%	-1.5%
insert u32/u64/str unique	1.400 ms, 2.0%	1.385 ms, 1.8%	-1.1%
insert u32/u64/str btree	1.498 ms, 1.0%	1.502 ms, 3.3%	+0.3%
iterate u32/u64/str	496.964 us, 1.2%	499.718 us, 1.7%	+0.6%
insert u32/u64/u64 unique	915.037 us, 1.5%	911.017 us, 1.1%	-0.4%
insert u32/u64/u64 btree	1.018 ms, 2.3%	998.853 us, 3.4%	-1.8%
iterate u32/u64/u64	268.507 us, 2.3%	258.697 us, 0.8%	-3.7%

The .NET 8 results are mostly flat, which is expected and I verified there's not a performance regression.

And kinda for fansies, this is the comparison between master on .NET 8 JIT and this PR on .NET 10 NativeAOT:

Benchmark	master .NET 8 JIT	PR .NET 10 AOT	AOT vs JIT	Speedup
large args 64KiB	521.910 us	45.970 us	-91.2%	11.4x
print_bulk lines=1	18.917 us	7.743 us	-59.1%	2.4x
print_bulk lines=100	308.638 us	67.650 us	-78.1%	4.6x
print_bulk lines=1000	2.924 ms	584.114 us	-80.0%	5.0x
circles load=10	794.400 ms	34.112 ms	-95.7%	23.3x
circles load=100	790.261 ms	33.919 ms	-95.7%	23.3x
ia_loop load=10	50.046 ms	10.660 ms	-78.7%	4.7x
ia_loop load=100	131.112 ms	27.503 ms	-79.0%	4.8x
filter string index	523.986 us	47.394 us	-91.0%	11.1x
filter u64 index	277.269 us	21.674 us	-92.2%	12.8x
insert u32/u64/str unique	1.400 ms	263.539 us	-81.2%	5.3x
insert u32/u64/str btree	1.498 ms	362.381 us	-75.8%	4.1x
iterate u32/u64/str	496.964 us	44.413 us	-91.1%	11.2x
insert u32/u64/u64 unique	915.037 us	166.006 us	-81.9%	5.5x
insert u32/u64/u64 btree	1.018 ms	247.646 us	-75.7%	4.1x
iterate u32/u64/u64	268.507 us	15.355 us	-94.3%	17.5x

[JasonAtClockwork]

The code looks fine but it seems NativeAOT is not allowing this to be monomorphic. I used the benchmarks-cs project as a test case and built the .wasm then pulled out the text format version of the binary with wasm-tools (wasm-tools print tool).

Reviewing the code through that lens what I can see is NativeAOT seems to be building a wrapper around the generics and ending up doing the exact same thing in the end using a lookup -> resolve interface -> call indirect.

In func $StdbModule_ModuleRegistration____call_reducer__ we see the switch statement run through some br_table command that breaks out each type to the same call $SpacetimeDB_Runtime_SpacetimeDB_Internal_Module____call_reducer___0<System___Canon> and inside that func we have:
call $__GenericLookupFromDict_SpacetimeDB_Runtime_SpacetimeDB_Internal_Module____call_reducer___0<System___Canon>_GCStaticBase_SpacetimeDB_Runtime_SpacetimeDB_Internal_Module_ReducerCache_1<R_System___Canon>
...
call $RhpResolveInterfaceDispatch
...
call_indirect (type 8)

This basically mirrors how the master branch has it (at least the resolve then call_indirect).

[lisandroct]

I addressed the huge point that Jason brought up and now we're where I was expecting to be initially.

[JasonAtClockwork]

After a detailed review this is looking fantastic. I've seen the same rough increases in speed and the Wasm output looks to be doing the correct work. On top of that the increase in binary size is negligible at ~0.39% increase for sdk-test-cs which has over 100 reducers.