Unite Austin 2017 - Writing High Performance C# Scripts

Summary

This Unite Austin 2017 presentation explains how Unity aimed to make large-scale C# simulations faster by moving from conventional object-oriented code toward data-oriented design, an Entity Component System (ECS), and a C# Job System.

Performance principles

• Memory layout matters. CPUs read memory in cache lines, and fetching data from RAM can take many cycles. Sequential access lets hardware prefetch upcoming data; scattered objects and pointers can cause cache misses and wasted bandwidth.
• Use contiguous data and separate hot from cold data. The speaker contrasts arrays of class instances with arrays of structs, then describes separating frequently used data—such as positions—from data not needed in the current loop. This improves locality and reduces unnecessary reads.
• Avoid costly patterns in performance-critical loops. The talk recommends minimizing virtual calls, garbage-collector allocations, and scattered object access. The broader goal is to keep data packed, iterate linearly, and process many entities in batches.
• These techniques are presented as especially useful for simulations with many units, complex AI, high frame rates, or mobile battery constraints.

ECS and entity workflows

The talk presents ECS as a way to separate component data from system behavior:

• Components hold data, often in structs; systems iterate over matching components and perform the work.
• Unity can maintain component data in arrays and let systems query entities with the required component combinations. The speaker describes both tuple-style queries and component groups.
• The approach can be adopted gradually: existing MonoBehaviour code can coexist with ECS while developers move performance-critical parts into systems.
• An entity manager handles entity and component creation, destruction, and updates. Prefabs can be instantiated through this system, and batched operations can reduce overhead.
• ECS memory is organized in chunks, with some control over which component data is stored together. The speaker emphasizes preserving contiguous iteration when entities are added or removed.

The demonstration centers on rotating and simulating large numbers of units. The speaker says the demo can spawn and destroy 100,000 units without per-frame GC allocations. The presentation also reports example timings: a loop over four components and 320 bytes of data, repeated 100,000 times, takes about 26 ms in the described comparison; destroying entities individually takes about 7.6 ms, versus about 0.9 ms with a batched API. These are figures quoted during the talk, not independent benchmarks.

Native containers and jobs

The C# Job System is shown as a way to run work across worker threads while checking access for unsafe data races.

• Jobs are structs that explicitly contain the data they access. The design restricts managed references and global access so the system can reason about job inputs and outputs.
• Native containers include NativeArray, NativeList, NativeSlice, NativeHashMap, and NativeMultiHashMap. They are intended for efficient access from jobs; some support concurrent operations.
• The allocator options described are Temp, TempJob, and Persistent, each with a different lifetime. Allocations must be disposed of manually; editor leak detection can help locate missed disposals.
• Jobs are scheduled and return handles. Handles can be completed when necessary or used to declare dependencies, allowing jobs to run in order without making the main thread wait prematurely.
• IJobParallelFor distributes iterations across workers, with a batch size controlling how work is grouped. Safety checks can report conflicting reads and writes.
• In the ECS job workflow, systems declare the component data they read and write. The system can use those declarations to track dependencies between jobs.
• A raycast-and-motion example illustrates chaining jobs: prepare raycast commands, run raycasts, inspect the results, and update entity positions.

Compiler and math tools

The talk also describes a compiler intended to optimize C# jobs:

• It can inline code and automatically vectorize suitable work, taking advantage of SIMD instructions.
• Developers can select optimization and precision settings. The speaker reports seeing 5–15× speedups in some cases, while noting that results depend on the work being performed.
• A proposed C# math library provides vector types such as float2, float3, and float4, along with common math operations and branch-free selection functions.
• The Q&A discusses deterministic compilation across CPU architectures as a goal, particularly for networked simulations. This is presented as planned work, not a demonstrated guarantee.

Demonstrations, guidance, and discussion

This is a technical presentation and code walkthrough rather than a product review. Its main examples cover:

1. Reworking object-oriented loops for cache-friendly data access.
2. Splitting component data from system behavior.
3. Scheduling parallel jobs and expressing dependencies.
4. Using jobs for large-scale unit simulation and raycast-based movement.
5. Comparing individual versus batched entity operations.

In the Q&A, the speaker also discusses possible audio and native-plugin integration through native containers, future physics and navigation APIs, profiling job waits and dependencies, and using custom components. He cautions that ordinary class-based components such as a renderer cannot simply be accessed from a job in the same way as native component data.

The release dates and availability mentioned are plans stated at the time of the 2017 talk. The speaker refers to previews, source code, and Unity releases as upcoming; those statements should not be taken as current availability information.

Main speaker and sources

• Main speaker: Joachim Ante, Unity co-founder and CTO, presenting at Unite Austin 2017.
• Other sources: Audience members asking questions during the Q&A; the talk’s demonstrations and performance figures are presented by the speaker.