> 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/optimized-accessors.md). # Build-Time Optimized Accessors Collapse a whole bound path into one generated method at build time. The [accessor layer](/binding-system-3/project-tools/performance.md#reflection-is-used-to-find-the-member-never-to-read-it) already turns a bound path into a chain of delegate calls, one per segment, with direct access for fields. Fast, but not free. For paths that are fully known before the game runs, the build can do better. The optimizer scans the project, finds those paths, and writes a **single direct static method** for each one. At runtime the accessor layer calls that method instead, so the whole path costs one call and nothing about it is resolved at runtime at all. Off by default. Turn it on in **Project Settings ▸ Binding System ▸ Configuration ▸ Build-Time Optimized Accessors**.

The optimized accessors manager, with its status card

## What qualifies A binding is a candidate when everything about it is deterministic:

Requirement	Why
Value source mode	A direct object reference. Every other mode resolves at runtime, so the source type is not known at build time.
Every path segment is public	A public field, a public auto-property, a public method, or a public indexer.
No provider syntax	Accessor providers resolve their own paths.
No open generics	The generated method needs a concrete type.
Parametric paths	Indexers and methods qualify only when the source is a reference type and the parameters are constants.
Long enough to be worth it	Below Min Path Pieces the runtime cost is already negligible and codegen is skipped.

A qualifying binding shows an **optimized badge** on its bind row, with the tooltip *This binding will be replaced by a generated direct-access method at build time*. That is how you find out per binding, without opening a window. ## The Optimized Accessors window Every candidate the scanner finds across the project: build scenes, non-build scenes, currently open scenes, Resources and their dependencies.

Rows are grouped by `(source type, path)`, since the same pair often appears in many places, and each one expands into its occurrences. Clicking an occurrence resolves it back to the live object and pings it, so you land on the actual bound field. **Build only** narrows the list to scenes that are in the build, which is the set that actually matters for a release. ## Settings

Setting	What it does
Generate Optimized Accessors	The master switch. Off by default.
Min Path Pieces	Paths with fewer pieces than this skip codegen. Indexers count as one piece.
On Stale Build	What happens when the build starts and the generated accessors would change: Ignore, Warn (default), or Fail Build.
Keep Generated File For Inspection	Keeps the file after the build instead of removing it. Off by default.
Generated Accessors Path	Where the file is written. Must be inside `Assets/`.
↻ Generate Now	Runs the scan and writes the file immediately, without building.

The status card above the settings says where things stand: *Never generated*, *Up to date*, *Out of date*, *Scanning project assets in the background*, or *Disabled*. The scan runs in the background and the settings page never blocks on it. ## What happens during a build 1. Before player compilation, the scanner runs and the writer emits the file. 2. The result is hashed and compared against the last recorded hash. A mismatch triggers the **On Stale Build** behaviour. 3. The player compiles with the generated accessors in it. 4. After the build, the file is removed, unless **Keep Generated File For Inspection** is on. A build aborted between the pre and post steps is cleaned up on the next editor load, so a cancelled build does not leave generated code in your project. {% hint style="info" %} Because the file is generated and removed per build, it is not something to commit. **Generated Accessors Path** points inside `Assets/` because the file has to be compiled with your code, not because it is meant to live there. {% endhint %} ## Choosing On Stale Build

Behaviour	What it does
Warn	The default, and right for local builds.
Fail Build	Right for CI. A stale set means the build machine is optimizing a different set of bindings from the one the project now has.
Ignore	When you know the difference is irrelevant and want silence.

## Is it worth turning on

Project	Is it worth it
Many bindings with deep paths, in built scenes	Yes. This is exactly the case it was built for.
Bindings mostly one or two segments deep	Little to gain. Min Path Pieces already skips those.
Bindings mostly using variable, tag or pattern sources	No. Those cannot be pre-resolved.
Tight CPU budget on a mobile target	Yes, and set On Stale Build to Fail Build.

Open the window before deciding. If it lists twelve candidates, the answer is no. ## Related pages * [Paths and Parameters](/binding-system-3/overview/paths.md): what a path can contain. * [Phased Bindings](/binding-system-3/project-tools/performance/phased-bindings.md): the other half of the runtime story. * [Benchmarks](/binding-system-3/project-tools/performance/benchmarks.md): measuring the effect.