> For the complete documentation index, see [llms.txt](https://postica.gitbook.io/binding-system-3/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://postica.gitbook.io/binding-system-3/project-tools/performance/benchmarks.md). # Benchmarks The numbers, and how to produce your own. ## How these numbers were produced Medians from the package's own performance suite, in **nanoseconds per call**, from two builds of the same project on the same machine: one on **IL2CPP**, one on **Mono**. Each cell gives IL2CPP first and Mono under it. One machine and one run apiece, so they are orders of magnitude rather than specifications. [Run the suite yourself](#running-them-yourself) before quoting a number. ## Against plain reflection The common assumption about a binding system is that it calls `FieldInfo.GetValue` on every read. This one does not: reflection is used once, when the path is first resolved, and never again while the game runs. Every test in the suite measures both, on the same object in the same run. | Access | Through `Bind` | Plain reflection | Faster by | | -------------------------------------------------------------------- | ----------------- | ---------------- | --------------- | | A **field**, read | 8.0 ns | 98 ns | **12x** | | A **field**, written | 7.6 ns | 75 ns | **10x** | | A **property**, read | 8.4 ns | 191 ns | **23x** | | A **property**, written | 9.2 ns | 178 ns | **19x** | | `SubStruct.vec2.x`, read | 32 ns | 464 ns | **15x** | | `SubStruct.vec2.x`, written | 39 ns | 798 ns | **20x** | | A field through the [field layer](#the-field-layer-on-its-own) alone | 1.4 to 2.5 ns | 62 to 256 ns | **25x to 180x** | IL2CPP figures. On Mono the ratios are the same or larger: a property write is 30x, a struct-property chain 63x. Two notes on the table. Reflection also **boxes** every value type it carries, which costs a frame rather than a microbenchmark, and the ratio does not show that. The two multi-hop rows are measured with [IL2CPP Specializations](/binding-system-3/project-tools/performance/il2cpp-specializations.md) on; with every optimization off they are 8x and 13x rather than 15x and 20x. ## One member | Path | Direct C# | The accessor | Through `Bind` | Plain reflection | | ----------------------- | ---------------------------------- | ---------------------------------- | ----------------------------------- | ---------------------------------- | | A **field**, read |

1.0 ns
Mono 1.5

3.7 ns
Mono 4.0

8.0 ns
Mono 9.8

98 ns
Mono 137

| | A **field**, written |

1.0 ns
Mono 1.4

3.2 ns
Mono 6.3

7.6 ns
Mono 9.2

75 ns
Mono 125

| | A **property**, read |

1.1 ns
Mono 2.0

7.0 ns
Mono 8.3

8.4 ns
Mono 13.3

191 ns
Mono 52

| | A **property**, written |

1.0 ns
Mono 2.4

5.4 ns
Mono 7.3

9.2 ns
Mono 11.9

178 ns
Mono 354

| A bound field read is **eight nanoseconds**. Updated every frame on a thousand objects, that is well under a tenth of a millisecond. The accessor column is the resolved member access. `Bind` adds **1.5 to 4.5 ns** on top of it: the bound-source check, the mode check and the pipeline entry. That delta is flat, so it matters less the more expensive the member is. ## Several hops A path through properties that return structs is the expensive shape: the value comes back, is walked into, and on a write is written back through the property it came from. These figures are with [IL2CPP Specializations](/binding-system-3/project-tools/performance/il2cpp-specializations.md) at **All**, which is the setting this shape needs on IL2CPP. | Path | Direct C# | The accessor | Through `Bind` | Plain reflection | | -------------------------------------------------------------------------------------- | ------------------------------------ | --------------------------------- | -------------------------------- | ----------------------------------- | |

SubStruct.vec2.x, read
property, property, field

0.9 ns
Mono 4.1

28 ns
Mono 7.2

32 ns
Mono 19

464 ns
Mono 619

| | `SubStruct.vec2.x`, written |

2.1 ns
Mono 9.6

36 ns
Mono 17

39 ns
Mono 22

798 ns
Mono 1395

| |

Transform.localScale.x, read
property, property, field

13.3 ns
Mono 14.8

22 ns
Mono 22

26 ns
Mono 41

429 ns
Mono 234

| The third row has a different baseline: `Transform.localScale.x` in plain C# is already 13 ns, because it is an engine call rather than a memory read. Against that, the binding is 2x on IL2CPP. ### The same paths with every optimization off

Path	Accessor, default	Accessor, specialized	Gain
`SubStruct.vec2.x`, read	59 ns	28 ns	2.1x
`SubStruct.vec2.x`, written	58 ns	36 ns	1.6x
`Transform.localScale.x`, read	75 ns	22 ns	3.3x

Through `Bind` the same rows go 61 to 32, 63 to 39 and 78 to 26 ns. On Mono nothing changes, because Mono has no such default cost. The reason is IL2CPP's handling of generics. A chain of up to four members is one compiled delegate calling each hop's compiled getter, and the getter of a property on a struct is a delegate typed on that struct, created at runtime for whatever types the path names. Mono compiles those for the exact types on first call. IL2CPP compiles ahead of time, has no code for an instantiation it never saw in the source, and falls back to a **shared** body that routes every value-type call through a runtime adapter. [IL2CPP Specializations](/binding-system-3/project-tools/performance/il2cpp-specializations.md) name those instantiations at build time, so IL2CPP compiles them specialised. On `Transform.localScale.x` that brings the accessor to 22 ns against Mono's 22: the backend difference on that path is gone. Single-member paths are unaffected by any of this, because `Bind` and its accessors are written out in ordinary code and were never shared. {% hint style="success" %} **Two settings address deep paths, and they are not alternatives.** [Generated accessors](/binding-system-3/project-tools/performance/optimized-accessors.md) replace a qualifying path at build time with one generated static method that does the whole walk inline. [IL2CPP Specializations](/binding-system-3/project-tools/performance/il2cpp-specializations.md) leave the pipeline in place and have IL2CPP compile it for the exact types; that reaches every binding, including the ones generated accessors refuse. For a hot binding on a deep path through struct properties, turn on both. {% endhint %} ## The field layer on its own Underneath the accessor, a field is reached by **pointer arithmetic**: take the object's address, add a byte offset fixed when the path was resolved, read. No `FieldInfo`, no delegate, no dispatch per segment. Measured on its own, without the accessor interface or the wrapper around it:

Field	This layer	Direct C#	Ratio	Plain reflection
A `Vector3`, read	1.7 ns Mono 4.0	1.1 ns Mono 2.3	1.6x Mono 1.7x	100 ns Mono 143
A `Vector3`, written	2.0 ns Mono 3.8	1.4 ns Mono 2.5	1.4x Mono 1.6x	77 ns Mono 133
A `Color`, read	1.7 ns Mono 4.5	0.9 ns Mono 2.5	1.9x Mono 1.8x	106 ns Mono 153
A `Color`, written	1.6 ns Mono 10.5	0.9 ns Mono 8.0	1.7x Mono 1.3x	77 ns Mono 135
A class reference, read	2.5 ns Mono 7.5	2.2 ns Mono 7.1	1.1x Mono 1.1x	62 ns Mono 83
A class reference, written	2.2 ns Mono 8.0	2.1 ns Mono 7.0	1.1x Mono 1.1x	73 ns Mono 101
`publicVector.y`, read	1.7 ns Mono 2.4	0.9 ns Mono 1.6	1.9x Mono 1.5x	190 ns Mono 303
`publicVector.y`, written	1.4 ns Mono 2.5	0.9 ns Mono 1.4	1.6x Mono 1.8x	256 ns Mono 409

Within a factor of two of the compiler's own field access on every row, and within ten percent for references, where there is nothing to copy. The last two rows are a **two-field chain** and cost no more than one field: consecutive value-type fields are collapsed into a **single** offset when the path is resolved, so `a.b.c` where all three are fields is one addition and one read. The suite measures that path written as one string and as separate segments, and both cost the same. Reflection cannot do that. Reading `publicVector.y` through `FieldInfo` means fetching the whole `Vector3`, boxing it, reading `y` out of the box, and on a write putting the box back, which is why those two rows are the dearest in the reflection column. {% hint style="info" %} **Allocation is the other axis, and it is the flat one.** A bound read or write of a value type allocates **nothing**. `ModifyDelegate` takes its value by `in`, so nothing is boxed on the way through. The suite checks this rather than asserting it: every measurement in `BindOverheadPerformanceTests` counts allocated memory alongside the time. On both runs above the median allocation of every row is **zero**, for the direct call, the accessor and `Bind` alike, over thirty thousand calls apiece. Each row records one measurement of under half a kilobyte, and the direct C# call records the same one, which places it in the harness rather than in the binding. {% endhint %} ## What each mechanism is worth

Feature	Result
Phased bindings	Measured on the same field through the same chain. With four static modifiers and an unchanged source, a read drops from 31 ns to 12 ns on IL2CPP and from 112 ns to 20 ns on Mono. With one modifier it is a wash on IL2CPP, and with none there is nothing to pay. On an update where the source did change, the phased read costs the fixed one plus about 10 ns for the compare and the cache write on a four-stage chain, and a chain led by a dynamic modifier costs the same as fixed. The measured table.
Generated accessors	Removes the per-segment walk entirely for qualifying paths. This is the one that addresses the multi-hop cost, which is the largest single number on this page.
IL2CPP specializations	On IL2CPP only, and on multi-hop paths only: measured at 1.6x to 3.3x off the accessor, and on `Transform.localScale.x` it closes the gap against Mono entirely. Single-member paths do not move. More code and memory in exchange.
Optimized Update	Proportional to how often the value is unchanged. On a stable value, close to free.
Intervals	Exactly linear. A 6-frame interval is a sixth of the work.

## Running them yourself Ratios from someone else's machine are a starting point, not an answer. The package ships its performance suite. 1. Install **Unity Performance Testing** (`com.unity.test-framework.performance`) via the Package Manager. That is the only step: the test assembly turns `ENABLE_PERFORMANCE_TESTS` on by itself through a version define, so there is nothing to add to the Player settings. 2. Open **Window ▸ General ▸ Test Runner**, **PlayMode** tab. 3. Run the classes below, under `Postica.BindingSystem.Tests`.

Test class	What it measures
`BindOverheadPerformanceTests`	The per-call overhead of the `Bind<T>` family over the accessor it delegates to. Four timed sample groups per test, on the same object and the same accessor instance: Direct, Reflection, Accessor and Bind, plus AllocatedKB.
`AccessorsFactoryTests`	Accessor construction and throughput across short and long paths.
`ReflectTests`	The fast field-access layer, against plain reflection and against direct C#. This is where the field layer numbers come from. Three sample groups per test: FastAccessor, Reflection, Direct.
`RegisteredAccessorPerfTests`	What a generated accessor is worth against the resolved one it replaces.
`PhasedPipelinePerformanceTests`	Phased against fixed, over the same field with the same modifier chain: zero, one, two and four static modifiers on a source that never changes, zero and four on one that changes every read, and a chain led by a dynamic modifier. Two sample groups: Fixed and Phased.

The Bind versus Accessor delta is the wrapper overhead, and it is the number the package is written to keep small. {% hint style="warning" %} Measure in a **build**, not in the editor, and on the platform you care about. Editor numbers include editor-only work, and the tables above show that IL2CPP and Mono disagree by up to eight times on the same path, in both directions. {% endhint %} ### Reading the exported results Each row is one sample group of one test, and the aggregate columns describe that test alone. Divide by the iteration count, 1000 for the bind tests and 100000 for the field-layer ones, to get nanoseconds per call. {% hint style="warning" %} **Results exported before 3.0.2 need care.** Until then the sample groups were static and shared across every test in a class, so each row carried its own samples *plus* every earlier test's, and the Median, Average and Standard Deviation columns described a mixture. The tell is a standard deviation larger than the median. In such a file only the per-sample **Values** column is sound, and one test's own figures are the **last thirty values** of its row. {% endhint %} ## Measuring your own scene The suite measures the package. For your project, the useful tool is the [Bindings Monitor](/binding-system-3/project-tools/diagnostics/bindings-monitor.md): 1. Enter play mode, let the scene settle, press **Reset**. 2. Play normally for a while. 3. Read **Total Exec Time** in the footer. That is your whole binding budget per update. 4. Sort by **Measurements** and see which rows own most of it. If the total is a fraction of a millisecond, you are done. If it is not, the [tuning order](/binding-system-3/project-tools/performance.md#a-tuning-order-that-works) is on the overview page. ## Build size

Feature	Result
Base package	The runtime assembly plus Mono.Cecil. The editor assemblies are not included in a build.
Phased bindings	Slightly larger, for the phase machinery.
Generated accessors	One generated method per optimized path, present only during the build.
Standard modifiers	One generated class per modifier kind per enabled type. This is why it is opt in.