Performance Benchmarks¶

This page shows the latest dispatch-throughput and cross-library comparison numbers for DxMessaging. The published tables come from a Release Standalone IL2CPP player, the same backend and build shape used by shipped games.

These numbers are for orientation, not a leaderboard. Real-world performance depends on what your handlers actually do; the benchmarks measure raw dispatch cost with minimal handler work. For the full methodology, CI mechanics, baseline capture, the regression smoke gate, and how to add or bump a comparison library, see the Perf Benchmark Methodology runbook.

See also: Performance optimizations for design details.

How to read these tables¶

• Scopes. Each dispatch table is labeled by execution scope and backend. Standalone (IL2CPP) -- a Release player on the ahead-of-time backend shipped games run -- is the only published scope. The renderer also understands PlayMode and EditMode rows for local or manually dispatched runs; backends differ by design, so read each scope against its own backend.
• Throughput. Reported as emits per second. Higher is better. Registration scenarios report wall-clock time instead, where lower is better. The published throughput numbers come from the Standalone (IL2CPP) leg.
• Allocations. Lower is better, and 0 means the measured operation did not allocate. Release IL2CPP players cannot expose Unity's allocation recorder, so the published Standalone tables omit allocation columns instead of showing a page of n/a values. Editor benchmark runs can include those columns.
• Comparison matrix N/A. The cross-library matrix has a column per scenario and a row per library. A cell shows N/A when that library does not idiomatically support that capability -- it is a capability gap, not a failure, and the value is never faked.
• Comparison matrix winners. In the throughput matrix the fastest technology per scenario column is rendered in bold (ties are all bolded; N/A never wins). The GC-allocations and GC-allocated-bytes matrices are not bolded: an allocation count or byte total is a property to read, not a race.

Latest CI dispatch throughput¶

The block below is regenerated from the latest benchmark run. It includes the Standalone IL2CPP dispatch table, cross-library comparisons, and the hardware summary needed to interpret the results. Do not edit it by hand.

Latest CI benchmark run: Unity 6000.5.2f1, commit e76cdbf7b3b3c87e3b57881cff3b93d5e6d7977a.

Runner: 13^th Gen Intel(R) Core(TM) i9-13900KF, 24C/32T @ 3000MHz; 64GB DDR5@4200; NVIDIA GeForce RTX 3060; Microsoft Windows 11 Pro N (10.0.26200)

Dispatch throughput - Standalone (IL2CPP)¶

Platform: Standalone IL2CPP x64 Release (WindowsPlayer; Unity 6000.5.2f1).

Library comparison - throughput (Standalone (IL2CPP))¶

Comparison libraries¶

The cross-library comparison matrices above measure DxMessaging against other common Unity messaging and eventing approaches on the same apples-to-apples scenarios:

• External libraries: MessagePipe, UniRx MessageBroker, Zenject SignalBus, and Unity Atoms.
• Zero-dependency baselines: plain C# event, UnityEvent, a ScriptableObject event channel, and Unity SendMessage.

Each library implements only the scenarios it idiomatically supports; unsupported cells render N/A. The comparison suite source lives in Tests/Runtime/Comparisons/. For a feature-by-feature discussion of when each approach wins, see the Comparisons guide.

Memory footprint and reclamation¶

Dispatch state is stored per message type and, for targeted and broadcast paths, per InstanceId. Long-running sessions accumulate slots for every type or entity ever touched unless something reclaims them. The memory reclamation system caps that growth without changing dispatch semantics or allocating during emit.

Reclamation runs on two paths:

• An idle sweep that runs from emit-time clock samples and the Unity PlayerLoop, gated by DxMessagingRuntimeSettings.EvictionEnabled and EvictionTickIntervalSeconds. Empty slots become eligible only after remaining empty for at least IdleEvictionSeconds of wall time.
• An explicit IMessageBus.Trim(force) and MessageHandler.TrimAll(force) pair that runs synchronously at scene boundaries, in tests, or in maintenance windows. The master switch EnableTrimApi controls whether the explicit calls perform work; idle sweeps remain controlled by EvictionEnabled independently.

Active registrations are never reclaimed. Only empty slots and shared pool entries are touched. Sweep work runs outside the hot handler loop, so emit throughput is unaffected; the per-emit overhead is one branch that samples the wall clock.

For tuning recommendations, the public Trim and diagnostic-counter API surface, and worked examples (scene transitions, leak diagnosis, mobile caps, shipped-title configurations), see the Memory Reclamation guide. For the parameter reference, see the Runtime Settings reference.