You are responsible for a comprehensive **game performance, frame-time, memory, loading, rendering, and scalability optimization pass**.

Your job is to make the existing game **run materially better**.

The primary question throughout this task is:

> **Where is the game actually wasting frame time, CPU time, GPU time, memory, bandwidth, loading time, or runtime resources — and what measurable improvements can safely eliminate that waste?**

Then fix those problems.

This is an **implementation task**, not merely a profiling report.

Do not stop after:

- identifying expensive functions;
- generating profiler captures;
- listing optimization opportunities;
- explaining performance theory;
- creating a performance backlog;
- recommending future benchmarking.

Profile the actual project where practical, identify real bottlenecks, prioritize them by impact, implement worthwhile optimizations, validate correctness, measure the result, and continue through progressively smaller meaningful performance problems.

The goal is:

> **Make the existing game faster, smoother, more stable, less wasteful, and more scalable without degrading intended gameplay, visual quality, correctness, responsiveness, or maintainability.**

---

# Measurement Before Optimization

The highest-level rule is:

> **Optimize evidence, not intuition.**

Do not rewrite code merely because it looks inefficient.

Do not assume:

- loops are slow because they are loops;
- allocations matter merely because they exist;
- object pooling is automatically better;
- ECS is automatically faster;
- multithreading is automatically better;
- GPU utilization is automatically bad;
- high memory usage is automatically a leak;
- low FPS automatically means the CPU is the problem;
- low FPS automatically means the GPU is the problem;
- caching automatically improves performance;
- reducing update frequency is automatically safe.

Establish evidence first whenever the available tooling permits.

Prefer:

- profiler captures;
- frame-time measurements;
- timing instrumentation;
- runtime statistics;
- memory snapshots;
- render statistics;
- GPU diagnostics;
- network metrics;
- database/query metrics;
- loading measurements;
- reproducible stress scenarios;
- before/after benchmarks.

If ideal profiling tools are unavailable, use the strongest evidence reasonably available.

Do not fabricate precision.

Do not claim measured improvements unless they were actually measured.

---

# Performance Is More Than Average FPS

Inspect performance across multiple dimensions.

Relevant concerns include:

- average frame time;
- worst recurring frame time;
- frame-time consistency;
- stutter;
- hitching;
- CPU utilization;
- main-thread time;
- worker-thread utilization;
- GPU frame time;
- render-thread time;
- draw calls;
- shader cost;
- overdraw;
- memory usage;
- memory growth;
- garbage collection;
- allocation rate;
- asset loading;
- scene loading;
- world streaming;
- startup time;
- network traffic;
- serialization;
- database operations;
- server tick time;
- simulation cost;
- scalability with entity count;
- scalability with player count;
- long-session degradation;
- periodic workload spikes.

A game running at a high average FPS with regular large hitches is not fully performant.

Prioritize **frame-time stability** as well as throughput.

---

# Core Scope

This pass owns **technical performance**.

Only optimize systems that actually exist.

## CPU

Relevant areas may include:

- update loops;
- tick loops;
- entity iteration;
- gameplay simulation;
- AI;
- pathfinding;
- physics;
- collision;
- animation processing;
- procedural systems;
- scripting;
- input processing;
- UI updates;
- repeated calculations;
- sorting;
- searching;
- data transformations;
- serialization;
- networking;
- background jobs.

## GPU

Relevant areas may include:

- draw calls;
- material count;
- shader complexity;
- shadows;
- lighting;
- transparency;
- particles;
- overdraw;
- post-processing;
- texture sampling;
- render targets;
- mesh complexity;
- batching;
- instancing;
- culling;
- LOD systems;
- UI rendering;
- expensive full-screen effects.

## Memory

Relevant areas may include:

- heap growth;
- garbage generation;
- unnecessary allocations;
- leaked resources;
- duplicated assets;
- oversized textures;
- retained objects;
- caches;
- pooling where justified;
- resource unloading;
- memory spikes.

## Loading

Relevant areas may include:

- startup;
- level or scene loading;
- world streaming;
- asset loading;
- shader compilation;
- resource initialization;
- save loading;
- networking initialization;
- database requests.

## Multiplayer and Server Performance

Where relevant:

- tick duration;
- player scaling;
- entity scaling;
- broadcast fan-out;
- serialization;
- database queries;
- network messages;
- interest management;
- redundant state updates;
- unnecessary polling;
- background tasks.

## Long-Running Stability

Look for:

- memory growth;
- leaked listeners;
- leaked objects;
- accumulating collections;
- unbounded caches;
- increasing tick cost;
- growing logs;
- stale entities;
- orphaned resources.

---

# Explicitly Out of Scope

This is **not primarily**:

- a visual redesign;
- a UI redesign;
- a gameplay redesign;
- an accessibility pass;
- a balancing pass;
- a general technical-debt cleanup;
- repository cleanup;
- content reduction;
- art-direction work;
- arbitrary graphics downgrading;
- a technology migration;
- a rewrite into a fashionable architecture.

Do not solve performance by casually degrading:

- visual quality;
- simulation accuracy;
- gameplay responsiveness;
- multiplayer correctness;
- world density;
- content;
- VFX;
- animation;

unless evidence shows the cost is unacceptable and an efficient equivalent or sensible scalable alternative can preserve intended quality.

---

# Preserve Correctness First

An optimization that changes intended results is not automatically an improvement.

Preserve:

- gameplay outcomes;
- simulation rules;
- authoritative state;
- network protocol behavior;
- persistence;
- save compatibility;
- collision behavior;
- timing semantics;
- entity lifecycle;
- deterministic behavior where required;
- rendering correctness;
- visual identity.

Be especially careful around:

- concurrency;
- caching;
- memoization;
- pooling;
- batching;
- asynchronous loading;
- resource reuse;
- network throttling;
- database caching.

These techniques can create subtle correctness bugs.

---

# Do Not Optimize Through Blind Quality Loss

Avoid:

> **Performance is low, therefore disable graphical features.**

Before reducing quality, investigate whether the real problem is:

- duplicated rendering;
- unnecessary updates;
- bad culling;
- excessive material changes;
- poorly structured effects;
- incorrect shadow configuration;
- accidental per-frame resource creation;
- unbounded entity work;
- synchronization stalls;
- inefficient shaders;
- redundant passes;
- unnecessary transparency.

Prefer making the implementation more efficient before reducing intended presentation.

When scalable quality reduction is genuinely appropriate, prefer:

- distance-dependent simplification;
- sensible LOD;
- dynamic quality behavior where appropriate;
- user-selectable quality settings;
- equivalent cheaper effects;

over permanently degrading the default presentation.

---

# Establish Performance Targets

First determine whether the project already specifies targets.

Possible targets include:

- target FPS;
- minimum hardware;
- supported platforms;
- target server tick rate;
- supported player count;
- supported entity count;
- loading expectations;
- memory limits.

Do not invent product requirements when none exist.

When explicit targets are absent, use practical relative goals:

- eliminate major hitches;
- reduce dominant bottlenecks;
- stabilize frame time;
- improve obviously excessive loading;
- prevent pathological scaling;
- remove confirmed leaks;
- reduce unnecessary memory churn;
- make representative gameplay materially faster.

Report measurements instead of pretending an arbitrary performance target was mandated.

---

# Establish Representative Performance Scenarios

Do not profile only an empty scene.

Identify scenarios representative of actual gameplay.

Depending on the game, these may include:

- startup;
- main menu;
- quiet gameplay;
- dense towns or hubs;
- wilderness;
- combat;
- many enemies or NPCs;
- particle-heavy encounters;
- gathering or production loops;
- large inventory or UI screens;
- complex environments;
- multiplayer with several players;
- server under representative load;
- scene transitions;
- asset-heavy areas;
- long-running sessions.

Also create targeted stress scenarios when useful for exposing scaling problems.

Do not optimize artificial benchmarks that do not resemble meaningful runtime behavior unless they isolate a real bottleneck.

---

# Establish a Baseline

Before substantial optimization, capture meaningful baseline data where practical.

Record only metrics relevant to the current project and scenario.

Possible metrics include:

- frame time;
- FPS;
- CPU frame time;
- GPU frame time;
- main-thread time;
- render-thread time;
- draw calls;
- triangles or vertices;
- allocations;
- garbage collections;
- memory;
- loading duration;
- server tick duration;
- query counts;
- network traffic;
- entity counts.

Do not obsess over collecting every possible metric.

Capture enough information to answer:

> **What is expensive now?**

and later:

> **Did the optimization actually help?**

---

# Investigate Before Asking Questions

Use the project and available profiling evidence before asking for clarification.

Inspect relevant:

- profiler data;
- source code;
- runtime statistics;
- renderer diagnostics;
- engine/project settings;
- build configuration;
- assets;
- scripts;
- database behavior;
- network behavior;
- deployment/server configuration;
- existing benchmarks;
- documented performance targets.

Ask for clarification only when:

- required performance targets cannot be established and materially affect a decision;
- hardware/platform requirements are ambiguous;
- visual-quality tradeoffs require a product decision;
- authoritative behavior is unclear;
- required external systems or hardware are unavailable;
- proceeding would create significant correctness risk.

Do not ask questions merely because profiling or investigation takes effort.

---

# Execution Strategy

Work autonomously where possible.

If the environment supports parallel agents, workers, subprocesses, or independent workstreams, use them where doing so materially helps.

Do not require delegation.

A single capable session should be able to execute this prompt sequentially.

When parallel work is available, good independent areas may include:

- CPU profiling;
- GPU profiling;
- memory investigation;
- loading investigation;
- UI performance;
- server performance;
- database performance;
- network traffic;
- asset-performance auditing.

Serialize changes when several workstreams involve the same:

- simulation loop;
- renderer foundation;
- entity architecture;
- resource manager;
- networking state;
- threading model;
- loading pipeline;
- shared cache.

Do not let independent workstreams apply conflicting optimizations to the same hot path.

Centralize cross-system tradeoffs.

---

# Implementation Over Reporting

The profile exists to create an **implementation queue**.

Do not spend most of the task:

- collecting endless profiler traces;
- narrating profiler output;
- listing suspicious code;
- producing optimization theory;
- generating speculative recommendations.

Once a bottleneck is understood well enough to improve safely:

> **implement the fix.**

Use this loop:

> **Measure → identify dominant cost → diagnose root cause → implement → validate correctness → measure again**

Continue while clear, material, safely actionable improvements remain.

---

# Performance Priority Queue

## P0 — Catastrophic Performance Problems

Examples:

- freezes;
- multi-second stalls;
- runaway memory growth;
- unbounded resource leaks;
- catastrophic server tick overruns;
- severe network storms;
- infinite or repeatedly duplicated work;
- loading deadlocks;
- extreme pathological scaling.

Fix these first.

## P1 — Player-Visible Bottlenecks

Examples:

- major frame drops;
- recurring hitches;
- poor frame-time stability;
- severe combat slowdown;
- dense-area slowdown;
- obvious server lag;
- long loading;
- frequent GC pauses;
- shader-compilation hitches;
- major UI stalls.

These strongly affect perceived quality.

## P2 — Meaningful Structural Waste

Examples:

- repeated expensive computation;
- inefficient entity iteration;
- unnecessary queries;
- redundant serialization;
- excessive draw calls;
- avoidable overdraw;
- unnecessary per-frame work;
- inefficient resource loading;
- repeated allocations;
- expensive polling.

Spend substantial effort here.

## P3 — Smaller Optimizations

Examples:

- modest hot-path cleanup;
- minor allocation reduction;
- small query improvements;
- small render-state reductions;
- secondary loading improvements.

Address these after important bottlenecks.

Do not spend significant time reducing a tiny cost while a dominant multi-millisecond bottleneck remains.

---

# Frame-Time First

Think in milliseconds.

Useful reference points:

- 30 FPS ≈ 33.3 ms/frame;
- 60 FPS ≈ 16.7 ms/frame;
- 120 FPS ≈ 8.3 ms/frame;
- 144 FPS ≈ 6.9 ms/frame.

Do not optimize based only on average FPS.

Identify:

- average frame time;
- slow frames;
- worst recurring frames;
- spikes;
- periodic stalls.

A meaningful reduction in the dominant frame path can be more valuable than dozens of micro-optimizations.

---

# CPU Profiling Pass

Inspect high-cost CPU work.

Common categories include:

- gameplay simulation;
- entity updates;
- AI;
- pathfinding;
- physics;
- animation;
- UI;
- networking;
- serialization;
- resource management;
- scripting;
- engine callbacks.

For expensive repeated work, ask first:

> **Why is this work happening this often?**

before asking:

> **How can this individual instruction be made faster?**

Eliminating unnecessary work is often more valuable than micro-optimizing necessary work.

---

# Update and Tick Loop Pass

Inventory expensive systems running every:

- frame;
- physics frame;
- simulation tick;
- server tick;
- fixed update;
- UI update.

For each ask:

- Does this need to run every frame?
- Does every entity need this update?
- Can unchanged state skip work?
- Can inactive entities avoid work?
- Can work become event-driven?
- Can updates be distributed over time?
- Can distant entities update less frequently without visible harm?
- Can results be safely cached?
- Can multiple passes be combined?

Do not indiscriminately convert everything to events.

Use the simplest efficient behavior appropriate to the system.

---

# Entity Scaling Pass

Measure how cost changes as entity counts increase.

Relevant entities may include:

- players;
- NPCs;
- enemies;
- projectiles;
- items;
- effects;
- world objects;
- interactables.

Look for:

- nested all-to-all checks;
- repeated global scans;
- per-entity scene searches;
- expensive component lookups;
- repeated pathfinding;
- redundant processing.

Ask:

> **If the entity count doubles, does the cost roughly double, quadruple, or become even worse?**

Prioritize pathological scaling.

---

# Search and Lookup Pass

Look for high-frequency:

- scene-tree searches;
- hierarchy traversal;
- object searches;
- list scans;
- dictionary rebuilds;
- component lookups;
- string-based lookups;
- database lookups.

Optimize only where profiling shows meaningful cost.

Possible improvements include:

- direct references;
- indexed structures;
- maintained lookup maps;
- spatial structures;
- bounded caches.

Do not create complex indexing systems for tiny collections.

---

# Allocation and Garbage Collection Pass

Inspect runtime allocation behavior.

Look especially at allocations inside:

- per-frame loops;
- entity loops;
- render preparation;
- network handling;
- serialization;
- UI refresh;
- temporary collections;
- string formatting;
- high-frequency transformations;
- frequently created closures where relevant.

Determine whether GC or equivalent memory management causes:

- spikes;
- frame-time instability;
- memory pressure.

Reduce high-frequency waste.

Do not contort readable low-frequency code merely to eliminate negligible allocations.

---

# Object Pooling Policy

Do not automatically pool everything.

Pooling is most useful when:

- creation/destruction is frequent;
- objects are expensive;
- allocation or GC contributes materially to stutter;
- lifecycle can be managed safely.

Pooling can create:

- stale state;
- lifecycle bugs;
- retained memory;
- additional complexity.

Use it only when evidence justifies it.

Ensure pooled objects reset completely before reuse.

---

# Memory Pass

Inspect:

- total usage;
- growth over time;
- large memory categories;
- retained resources;
- duplicated assets;
- texture memory;
- mesh memory;
- audio memory;
- caches;
- entity/object counts.

Distinguish:

> **high but stable intentional memory use**

from:

> **unbounded growth or unnecessary retention**

Look for:

- objects that never release;
- resources retained after scene transitions;
- static collections accumulating entries;
- listeners retaining dead objects;
- caches without limits;
- duplicate asset loading.

---

# Long-Session Stability Test

Where practical, exercise repeated behavior such as:

- scene changes;
- combat;
- spawning/despawning;
- UI opening/closing;
- connect/disconnect cycles;
- resource loading/unloading.

Observe:

- memory growth;
- increasing frame time;
- increasing tick time;
- listener accumulation;
- collection growth;
- resource retention;
- periodic spikes.

Performance after a long session can matter more than performance during the first minute.

---

# Determine CPU vs GPU Bottleneck

Determine whether representative scenarios are primarily:

- CPU-bound;
- GPU-bound;
- synchronization-bound;
- mixed.

Do not reduce GPU visual quality to solve a CPU bottleneck.

Do not rewrite CPU systems when GPU frame time clearly dominates.

Use appropriate diagnostics when available.

---

# Draw-Call Pass

Inspect draw calls where relevant.

Look for:

- many identical objects failing to batch;
- unnecessary material variation;
- duplicated materials;
- broken instancing;
- UI producing excessive draws;
- tiny decorative objects with disproportionate rendering cost.

Possible improvements include:

- instancing;
- batching;
- material consolidation;
- atlasing where appropriate;
- reducing unnecessary render-state changes.

Do not merge everything into giant inflexible assets merely to reduce a number.

---

# Material and Shader Performance Pass

Inspect expensive shared shaders.

Look for:

- unnecessary texture samples;
- expensive branches;
- heavy transparency;
- complex per-pixel effects;
- duplicate passes;
- expensive effects covering large screen areas.

Optimize while preserving intended appearance.

If simplification visibly degrades quality, investigate:

- a cheaper equivalent;
- distance-based simplification;
- LOD;
- quality settings;
- alternate implementation strategies.

Do not casually undermine established art direction.

---

# Transparency and Overdraw Pass

Inspect:

- particles;
- foliage;
- UI;
- transparent decals;
- overlapping effects;
- large transparent quads.

Reduce waste through techniques such as:

- tighter bounds;
- fewer unnecessary overlapping layers;
- stopping off-screen effects;
- controlled particle counts;
- opaque alternatives where visually equivalent.

Do not destroy atmosphere merely to reduce transparency.

---

# Lighting and Shadow Cost

Inspect:

- dynamic lights;
- shadow-casting lights;
- shadow distance;
- shadow resolution;
- overlapping lights;
- per-object shadow cost.

Look for lights or shadows that provide little visible benefit relative to their cost.

Prefer targeted optimization.

Do not simply disable visual-polish work.

---

# Particle and VFX Performance

Inspect:

- active system count;
- particle count;
- transparent area;
- update cost;
- collision;
- lifetime;
- off-screen behavior;
- duplicated effects.

Look for systems that remain active while invisible.

Reduce unnecessary work while preserving intended presentation.

---

# Culling Pass

Determine whether invisible or irrelevant objects continue performing expensive work involving:

- rendering;
- animation;
- AI;
- particles;
- effects;
- nonessential updates.

Use appropriate:

- frustum culling;
- occlusion where supported;
- distance culling;
- visibility-aware updates;
- activation ranges.

Do not disable authoritative simulation merely because an object is not currently visible.

Separate:

> **rendering relevance**

from:

> **simulation relevance**

---

# LOD Pass

Where appropriate, determine whether distant or low-priority objects can safely use:

- simpler meshes;
- simpler materials;
- fewer particles;
- cheaper animation;
- reduced update frequency.

Do not build a large LOD pipeline unless the scale of the project justifies it.

Use evidence.

---

# Animation Performance

Inspect:

- number of animated entities;
- skeleton complexity;
- animation updates for invisible entities;
- blending cost;
- procedural animation;
- animation-state calculations.

Potential improvements may include:

- visibility-aware animation;
- distance-based update rates;
- shared animation data;
- reduced unnecessary blending.

Preserve presentation quality for nearby important characters.

---

# Physics Pass

Profile relevant:

- collision pair count;
- rigid bodies;
- triggers;
- raycasts;
- shape casts;
- navigation queries;
- continuous collision;
- collision layers and masks.

Look for:

- per-frame casts that do not need to occur every frame;
- overly broad masks;
- inactive objects remaining simulated;
- excessive query frequency.

Do not weaken collision correctness merely to improve benchmark numbers.

---

# Pathfinding Pass

If pathfinding exists, inspect:

- requests per second;
- repeated requests for identical destinations;
- unnecessary recomputation;
- path complexity;
- synchronous blocking;
- many entities pathfinding simultaneously.

Potential improvements may include:

- request coalescing;
- behaviorally safe cooldowns;
- cached paths where valid;
- spatial or hierarchical optimization;
- distributed path calculations;
- asynchronous processing.

Be careful not to harm interaction responsiveness.

---

# AI Performance Pass

Inspect whether AI performs expensive work unnecessarily.

Potential issues include:

- global searches every frame;
- expensive perception checks;
- pathfinding every tick;
- decision systems running too frequently;
- distant/inactive entities fully simulating.

Consider behaviorally safe:

- update scheduling;
- sleeping;
- spatial indexing;
- event-driven triggers;
- reduced distant update frequency.

Do not visibly degrade nearby AI behavior to save negligible CPU time.

---

# UI Performance Pass

Inspect:

- layout rebuilding;
- text regeneration;
- list reconstruction;
- full-screen refreshes;
- inventory grids;
- data binding;
- repeated sorting;
- tooltip generation;
- hidden UI continuing to update.

Look for interfaces rebuilding entire structures when only one value changed.

Optimize high-frequency paths while preserving UI correctness.

---

# Loading-Time Pass

Measure important loading transitions.

Break loading into components where possible:

- file I/O;
- asset decoding;
- scene construction;
- shader compilation;
- networking;
- database requests;
- initialization;
- resource conversion.

Fix dominant contributors.

Do not hide excessive loading behind prettier animations and call that optimization.

---

# Startup Pass

Inspect startup for unnecessary work.

Potential issues include:

- loading assets not immediately needed;
- connecting optional services serially;
- rebuilding caches every launch;
- scanning large directories;
- eagerly loading all configuration or resources.

Use deferred or lazy initialization where safe and beneficial.

Do not merely move every startup cost into the first gameplay frame and create new hitches.

---

# Streaming and Asynchronous Loading

Where the project supports or clearly benefits from streaming, inspect:

- blocking loads;
- synchronous resource creation;
- loading spikes;
- duplicate loads;
- poor preload decisions.

Use asynchronous work carefully.

Avoid introducing:

- race conditions;
- missing resources;
- placeholder flashing;
- late gameplay stalls.

Treat significant shared asynchronous-loading changes as high-risk engineering work.

---

# Database Performance

Where relevant, inspect actual database behavior.

Look for:

- N+1 queries;
- missing useful indexes;
- repeated identical reads;
- oversized result sets;
- unnecessary writes;
- long transactions;
- full-table scans;
- excessive polling.

Use query plans and actual workload evidence where available.

Do not add indexes blindly.

Remember that indexes can increase:

- write cost;
- storage;
- maintenance cost.

Optimize against real usage.

---

# Server Tick Performance

For authoritative servers, measure tick duration under representative load.

Break down relevant:

- simulation;
- AI;
- movement;
- combat;
- persistence;
- networking;
- serialization;
- housekeeping.

Ensure worst-case tick time fits the intended simulation cadence where practical.

Look particularly for periodic work causing large spikes.

---

# Network Performance

Inspect:

- messages per second;
- bytes per second;
- redundant state;
- repeated full snapshots;
- duplicate events;
- overly frequent updates;
- serialization cost;
- broadcast fan-out.

Potential optimizations may include:

- delta updates;
- interest management;
- batching;
- safe frequency reduction;
- smaller representations.

Do not reduce authoritative correctness or make player-visible state unacceptably stale merely to reduce bandwidth.

---

# Interest Management

For multiplayer games with large worlds or many entities, determine whether clients receive updates for irrelevant:

- entities;
- world objects;
- effects;
- distant events.

Where architecture supports it, reduce irrelevant work based on:

- location;
- zones;
- visibility;
- relevance;
- interaction range.

Interest management can improve both CPU and bandwidth.

Treat major changes as shared high-risk multiplayer infrastructure.

---

# Serialization Pass

Measure repeated serialization and deserialization.

Look for:

- serializing identical data repeatedly;
- oversized payloads;
- repeated conversions;
- unnecessary temporary objects;
- expensive text representations in genuine hot paths.

Optimize where evidence shows meaningful cost.

Do not replace stable readable protocols merely to save negligible CPU time.

---

# Logging Performance

Inspect high-frequency logging.

Look for:

- logs inside frame or tick loops;
- logs per entity;
- repeated error spam;
- expensive string formatting;
- synchronous file writes.

Remove or reduce inappropriate runtime logging.

Preserve useful diagnostics.

Do not silence meaningful failures merely for performance.

---

# Periodic Spike Hunt

Some of the worst performance problems happen intermittently.

Look for work triggered:

- every second;
- every few seconds;
- every minute;
- during autosave;
- during garbage collection;
- during telemetry flush;
- during database cleanup;
- during world updates;
- during cache maintenance.

Profile for long enough to expose recurring spikes.

Averages can hide them.

---

# Cache Policy

Caching can dramatically improve performance.

It can also create stale state and memory growth.

Before adding a cache, establish:

- cost being avoided;
- invalidation rules;
- ownership;
- lifetime;
- maximum size;
- correctness implications.

Do not create caches merely because "caching is faster."

Prefer immutable or clearly invalidated cached data.

---

# Data Structure Pass

For proven hot paths, determine whether current data structures match actual access patterns.

Potential issues include:

- repeated list scans;
- expensive removals;
- excessive sorting;
- inappropriate lookup structures;
- repeated container conversions.

Choose structures based on actual operations.

Do not replace simple small collections with complicated structures without measurable need.

---

# Concurrency and Threading

Do not introduce multithreading casually.

Concurrency can add:

- synchronization cost;
- race conditions;
- deadlocks;
- nondeterminism;
- debugging complexity.

Use concurrency only when:

- work is genuinely parallelizable;
- profiling shows meaningful main-thread pressure;
- engine and platform constraints permit it;
- correctness can be maintained;
- expected benefit justifies complexity.

For substantial concurrency work, explicitly establish:

1. shared state;
2. thread ownership;
3. synchronization boundaries;
4. ordering requirements;
5. cancellation/lifecycle behavior;
6. determinism requirements;
7. regression tests;
8. measured benefit.

---

# Performance Versus Complexity Gate

Every optimization introduces maintenance cost.

Before a complex optimization ask:

> **How much measurable performance does this buy?**

Compare that benefit against:

- code complexity;
- regression risk;
- memory cost;
- platform complexity;
- debugging difficulty;
- maintenance burden.

Prefer simple optimizations with strong wins.

Reject cleverness that saves negligible time.

---

# Performance Versus Visual Quality Gate

For optimizations affecting rendering, evaluate both sides.

Ask:

> **What performance improvement do we gain?**

and:

> **What visible quality do we lose?**

Prefer:

- invisible optimization;
- efficient equivalents;
- distance-dependent reductions;
- scalable settings;

over indiscriminate quality loss.

---

# Performance Versus Responsiveness Gate

Do not reduce update frequency in ways that make:

- input sluggish;
- combat delayed;
- targeting stale;
- AI visibly unresponsive;
- UI noticeably laggy.

A performance optimization that damages game feel may be a net loss.

Use different update priorities for different systems where appropriate.

---

# Benchmark Discipline

Benchmarks should be reproducible enough to compare.

For important optimizations:

1. use the same scenario;
2. use comparable settings;
3. use comparable entity counts;
4. use comparable hardware where possible;
5. allow warm-up where relevant;
6. capture enough samples to avoid one-frame conclusions;
7. compare before and after.

Do not claim a large improvement because one run happened to be faster.

Use reasonable statistical evidence when practical.

---

# Work in Performance Waves

Do not optimize randomly.

## Wave A — Catastrophic Problems

Fix:

- stalls;
- leaks;
- runaway work;
- severe bottlenecks;
- pathological scaling.

Measure.

Validate.

## Wave B — Dominant Frame-Time Bottlenecks

Determine where most frame time is spent.

Optimize the largest justified contributors first.

Measure.

Validate.

## Wave C — Memory and Loading

Address relevant:

- allocations;
- GC;
- retained resources;
- loading;
- startup;
- streaming.

Measure.

Validate.

## Wave D — Scaling

Test relevant:

- dense scenes;
- entity counts;
- player counts;
- network load;
- server tick load.

Fix meaningful scaling problems.

Measure.

Validate.

## Wave E — Secondary Hotspots

Address smaller but still meaningful hotspots.

Avoid premature micro-optimization.

---

# Reassess After Every Wave

After every major optimization wave ask:

- What is the dominant bottleneck now?
- Did removing one bottleneck expose another?
- Is the game now CPU-bound instead of GPU-bound?
- Did frame-time consistency improve?
- Did memory improve?
- Did loading improve?
- Has the bottleneck moved elsewhere?
- Did optimization introduce complexity?
- Did visual quality regress?
- Did gameplay responsiveness regress?
- Did memory retention increase?
- Is further optimization still worth its risk?

Reprofile.

Do not continue optimizing a bottleneck that no longer matters.

---

# Productive Performance Loop

Do not stop after the first performance win.

Performance work frequently shifts the bottleneck.

Examples:

- CPU optimization exposes GPU cost;
- rendering optimization exposes simulation cost;
- allocation reduction exposes pathfinding;
- server simulation optimization exposes serialization;
- query optimization exposes network fan-out.

Continue:

> **measure → identify dominant cost → diagnose → implement → validate → measure again**

while clear, material, safely actionable improvements remain.

Do not manufacture work merely to continue optimizing.

Stop when remaining findings are:

- negligible;
- below measurement noise;
- disproportionately complex;
- likely to degrade quality;
- speculative;
- outside scope;
- dependent on unavailable hardware or services.

---

# Stress Testing

Where safe, exceed ordinary load deliberately.

Examples:

- more entities;
- more effects;
- more players;
- larger inventories;
- repeated scene changes;
- repeated spawning;
- intense combat;
- high network activity.

The goal is not to require the game to support absurd loads.

The goal is to reveal:

- nonlinear scaling;
- hidden leaks;
- catastrophic thresholds;
- synchronization bottlenecks;
- failure modes.

---

# "Where Did the Frame Go?" Review

For slow representative frames, account for the meaningful frame-time budget.

Ask:

> **What consumed the frame?**

Break the frame down until dominant work is understood well enough to act.

Do not accept:

> **The game is just heavy.**

Find the systems responsible.

---

# "Why Is This Running?" Review

For every unexpectedly expensive repeated operation, ask:

> **Why does this need to execute right now?**

This may reveal:

- redundant polling;
- unnecessary refreshes;
- updates on inactive entities;
- duplicate serialization;
- repeated resource loads;
- repeated queries;
- duplicated calculations.

Eliminating unnecessary work is usually preferable to making unnecessary work slightly faster.

---

# "Does This Scale?" Review

For important systems ask what happens when:

- player count doubles;
- entity count doubles;
- inventory size doubles;
- world object count doubles;
- network recipients double.

Look for algorithms that scale poorly.

Do not redesign systems around hypothetical growth when the collection is inherently tiny and bounded.

Focus on realistic growth.

---

# Independent Final Performance Review

Near completion, review performance again from fresh context.

Where applicable, separately evaluate:

## CPU

Find remaining expensive recurring work.

## GPU

Find dominant rendering cost and unnecessary GPU work.

## Memory

Find leaks, retention, large avoidable allocations, or memory spikes.

## Loading

Inspect startup and important transitions.

## Server / Network

Inspect scaling, tick time, queries, serialization, and traffic.

Require evidence.

The purpose of fresh review is to challenge the current result, not merely approve previous work.

---

# "What Still Feels Poorly Optimized?" Review

Ask:

> **What remaining technical-performance behavior would make a player think this game is poorly optimized or unfinished?**

Look for:

- hitching;
- loading pauses;
- stuttering;
- dense-area slowdown;
- UI stalls;
- long startup;
- memory growth;
- delayed asset appearance;
- server tick spikes;
- performance-caused rubber-banding;
- periodic freezes;
- shader compilation stalls.

For each meaningful finding establish:

### Scenario

Where does it occur?

### Symptom

What does the player experience?

### Evidence

What measurement or reproducible observation supports it?

### Cause

What appears responsible?

### Proposed Fix

What concrete optimization is justified?

### Scope

Tiny / Small / Medium / Large.

Implement worthwhile findings.

Reject guesses without evidence.

---

# Anti-Optimization Review

Before completion, inspect whether this pass introduced bad optimization practices.

Ask:

- Did we add unnecessary caches?
- Did we create stale-state risk?
- Did we over-pool?
- Did we introduce threading without sufficient benefit?
- Did we make simple code unnecessarily difficult to understand?
- Did we create custom data structures for tiny collections?
- Did we reduce visual quality unnecessarily?
- Did we reduce update frequency enough to hurt responsiveness?
- Did we create memory retention while reducing allocations?
- Did we optimize code that was not actually hot?
- Did maintenance cost increase for microscopic gains?
- Did we move work rather than eliminate it?

Undo unjustified complexity.

Performance engineering should make the game **faster**, not merely make the code more clever.

---

# Final Regression Validation

Before finishing, verify relevant:

- gameplay correctness;
- simulation results;
- visual quality;
- animation;
- physics;
- networking;
- persistence;
- UI;
- loading;
- resource lifecycle.

Specifically search for optimization-induced problems such as:

- stale caches;
- missing updates;
- dirty pooled objects;
- race conditions;
- incorrect culling;
- invisible objects;
- visual popping;
- reduced responsiveness;
- desynchronized multiplayer state;
- resources unloaded while still referenced;
- nondeterministic behavior where determinism matters.

Fix regressions.

---

# Final Performance Measurement

Repeat representative baseline scenarios.

Compare meaningful before/after results.

Report only metrics that were actually measured.

Possible metrics include:

- frame time;
- recurring frame spikes;
- CPU time;
- GPU time;
- memory;
- allocations;
- GC frequency or duration;
- load time;
- tick time;
- query count;
- network volume.

Do not invent values.

If exact measurement was unavailable, describe qualitative improvements and limitations honestly.

---

# Completion Standard

The performance pass is complete when, to the degree available profiling can establish:

1. major performance scenarios have been examined;
2. dominant bottlenecks were identified using evidence;
3. catastrophic stalls or leaks discovered in scope are fixed;
4. major frame-time bottlenecks are reduced where safely actionable;
5. frame-time consistency is improved where problems existed;
6. major avoidable per-frame or per-tick work is reduced;
7. meaningful unnecessary allocations are reduced;
8. significant memory leaks discovered are fixed;
9. major resource-retention problems are corrected;
10. loading bottlenecks are improved where practical;
11. obvious render waste is reduced;
12. major GPU bottlenecks are improved without unnecessary visual degradation;
13. important entity/player scaling problems are improved;
14. server tick performance is improved where relevant;
15. unnecessary network work is reduced where relevant;
16. major database/query inefficiencies are reduced where relevant;
17. meaningful before/after evidence exists for major optimizations;
18. gameplay correctness remains intact;
19. visual presentation remains intact unless a justified scalable tradeoff was implemented;
20. game feel and responsiveness remain intact;
21. no known optimization-induced regressions remain;
22. complexity introduced by optimization is justified by measurable benefit;
23. remaining performance opportunities are small, speculative, disproportionately risky, hardware-specific, or better suited to deeper specialized work.

The objective is not:

> **maximum FPS at any cost**

The objective is:

> **maximum meaningful improvement in frame-time stability, throughput, loading, memory efficiency, scalability, and runtime smoothness while preserving the quality and correctness of the existing game.**

---

# Final Report

When complete, provide a concise performance report.

## 1. Overall Result

Summarize the largest performance improvements.

## 2. Baseline

State representative starting measurements actually collected.

## 3. Major Bottlenecks

Describe dominant costs discovered.

## 4. CPU Improvements

List meaningful changes and measured impact.

Omit if none.

## 5. GPU / Rendering Improvements

List meaningful changes and measured impact.

Omit if none.

## 6. Memory and Allocation Improvements

Summarize relevant:

- leaks;
- retention;
- allocations;
- garbage collection;
- asset memory.

## 7. Loading Improvements

State meaningful startup, transition, or loading improvements.

## 8. Server / Network / Database

Include only areas that actually exist.

Summarize meaningful improvements.

## 9. Scaling

Describe relevant tests involving:

- entities;
- players;
- effects;
- world size;
- other representative load.

## 10. Validation

State exactly what was performed, including relevant:

- profiler scenarios;
- benchmarks;
- stress tests;
- builds;
- runtime checks;
- regression tests.

## 11. Before / After

Provide important measured comparisons.

Do not invent values.

## 12. Deliberately Unchanged

Describe significant suspected issues left unchanged because:

- evidence was weak;
- impact was negligible;
- optimization risk exceeded benefit;
- unavailable hardware prevented validation;
- quality loss would be unacceptable;
- the issue belongs to another specialized pass.

## 13. Remaining Opportunities

List only genuinely worthwhile future performance work.

For each include:

- **Opportunity**
- **Evidence**
- **Expected benefit**
- **Scope:** Tiny / Small / Medium / Large
- **Relevant system**
- **Recommended priority**

Do not fill this section with speculative micro-optimizations.

---

# Final Directive

**Think like a performance engineer with a profiler, not a programmer hunting for code that looks slow.**

Measure first.

Prioritize what dominates actual runtime cost.

Do not optimize cold code.

Do not perform speculative micro-optimization.

Do not blindly add caches.

Do not blindly add pooling.

Do not blindly add threading.

Do not sacrifice visual quality merely because disabling something is easier than optimizing it.

Do not sacrifice game feel to reduce update frequency.

Do not sacrifice correctness for benchmark numbers.

Repeatedly ask:

> **Where is the time actually going?**

> **Why is this work happening?**

> **Can we eliminate the work rather than merely make it slightly faster?**

> **What does the profiler say is the dominant bottleneck now?**

Continue:

> **measure → diagnose → implement → validate → measure again**

while meaningful performance improvement remains.

Leave behind the **same game**, but make it run substantially smoother, more consistently, more efficiently, and more scalably.