Performance investigation Updated 07 November 2026

Faster colonies.
The same simulation?

What makes a large colony slow, which optimizations preserve its state, and where faster computation changes the answer.

BLUF Recommendation first

Rebuild main with exact changes.
Keep the numerical defaults.

Keep the qualified parcel caches and const reads in 40a1465 for your Windows rebuild: 8.67% less native work and +8.39% observed base throughput. The completed follow-up adopted no further runtime prototype. Focus next on fluid calculation. Keep numerical defaults unchanged; extra overlap remains unadopted. Sustained, smooth 3× remains unproven.

See the strongest evidence
Linux research · two large coloniesRuntime wins · 40a1465 · follow-up complete

01 / Landed exact changes · 07 Nov

Less repeated work.
Identical endpoints.

The candidate combines two pass-local parcel wire caches with const reads that avoid copying untouched cell chunks. Physical operations, solver arithmetic, checkpoint format and the existing inventory limits are preserved.

The full 3,000-tick ABBA replay is complete. Its result measures native work, not an automatic whole-game speedup.

Measured · Linux checks passed

07 Nov · matched native replay

8.67% less native work

Lower is better
Control Exact candidate
Mean owner tick−8.67%
93.746 ms
85.619 ms
Mean transfer stage−53.03%
19.218 ms
9.027 ms
Worst owner tick1,003 → 150 ms
1,003.417 ms
150.318 ms
Each pair has its own scale. Four fresh 3,000-tick replays in ABBA order: control, candidate, candidate, control. The first 150 ticks per run are excluded, leaving 5,700 warmed samples per side.

All four final full-owner hashes match. All 128 short owner images also match across both colonies at 1 and 12 workers. Full-cycle equality compares the endpoints, not every intermediate checkpoint.

Replay spread, tail latency and memory limits

The two control run means were 96.1888 and 91.3033 ms; candidate means were 85.6332 and 85.6048 ms. The aggregate uses both controls. Lower mean work corresponds to about 9.49% more native capacity, with no automatic equivalent game-speed claim.

Owner p99 fell from 215.236 to 123.837 ms; worst transfer time fell from 919.964 to 38.960 ms. Maximum mass/energy errors are unchanged at 3.58023e−15 / 2.62020e−16.

Mean peak replay RSS was 4,378.1 → 4,387.5 MiB. No memory saving was demonstrated. Replay memory includes the large journal and parsed inputs; it is not game RSS.

What the exact changes do

The admission cache maintains the encoded-size total during a transfer pass. The release cache validates the retained inventory once, then checks the changed entry and the same aggregate limits. Refused changes preserve the original parcel and cached totals. These caches add no persistent save state.

Const reads for occupied-volume initialization, neighbor snapshots and heat/energy queries inspect untouched cell storage without triggering copy-on-write chunk copies. The synthetic operation benchmarks above explain that mechanism; their RSS reductions do not establish game-memory savings.

Historical comparison · 6 November experiment

The earlier parcel-cache-only ABBA experiment measured 89.754 → 78.639 ms per native tick (12.38% less work), 18.433 → 8.504 ms in transfers, and 967.313 → 141.571 ms worst owner ticks. Its endpoints also matched, and no meaningful memory saving was demonstrated.

Those are historical results from a separate cohort. The current headline uses the fresh 7 November control/candidate comparison, including the const reads.

02 / Latest in-game result · 07 Nov

The base improves.
SO remains constrained.

Game speed is game seconds per wall second. A 1.00× result is real time; 3.00× is the requested speed.

These are ordered live pairs. Inputs vary with scheduling, and external video work continued on the shared host. Observed changes are not isolated causal estimates or exactness proofs.

32-duplicant industrial base

Fresh full cycle · ≈600 game seconds
ConfigurationGame speed
Unchanged Fresh control
1.402×
Exact candidate Two parcel caches + const reads
1.520×

Bar scale: 0–3×. Observed throughput +8.39%, calculated from the full-precision game/wall durations. Both runs retained 32 duplicants, completed a natural Cycle 2 autosave, passed telemetry and had no owner fault. Mean Unity-frame time was effectively unchanged at 44.32 → 44.24 ms: fewer owner stalls do not establish smoother input.

Live timing denominators and memory samples

Control: 601.125351 game seconds / 428.755517 wall seconds. Candidate: 600.925278 / 395.422162. Warm throughput was 1.405179 → 1.527181× (+8.68% observed); warm owner time was 110.03684 → 97.38421 ms.

Peak sampled game RSS was 4.154499 → 4.191223 GiB; managed heap was 1.639282 → 1.611649 GiB. These samples do not demonstrate a whole-game memory saving.

Spaced Out! · fresh 900-tick pair · 07 Nov

No useful SO gain established

1.069× Control1.038× Exact candidate

This live pair observed −2.93% throughput, or −4.10% after warmup. Both runs retained all 14 duplicants, passed telemetry and had no owner fault. A fresh fixed-input follow-up did not reproduce that penalty; it also established no useful SO gain.

SO slowdown investigation: live pair and matched follow-up

The control advanced 180.939209 game seconds in 169.249933 wall seconds; the candidate advanced 180.739258 in 174.164151. Warm rates were 1.103635 → 1.058389×, with warm owner means 160.52 → 165.94 ms.

The live result prompted a fresh 450-tick captured-input ABBA comparison: 50 warmup ticks excluded per run, leaving 800 warmed samples per side. Old run means were 157.693 / 150.583 ms; new means were 151.158 / 153.153 ms. Combined means were 154.138 → 152.156 ms (1.29% less work), with overlapping run ranges.

This 90-game-second fixed-input test did not reproduce the live penalty and does not establish a useful SO gain. It does not replace the approximately 180-game-second live observation. All four follow-up endpoint hashes match; maximum relative mass/energy errors match at 5.503e−15 / 2.201e−15. The extra capture was diagnostic, not another timed live comparison.

SO sampled RSS was 4.971 → 4.861 GiB and managed heap 2.131 → 2.053 GiB. A single pair does not establish a lasting memory reduction. The observed mean Unity-frame times were 30.65 → 31.36 ms.

Historical live results · 6 November

The earlier base cohort observed 1.297 → 1.559× with parcel caches (+20.22%). Its multigrid + 1 mL detail run reached 1.932×, and the full numerical/cache combination reached 2.093×. These ordered, shared-host observations do not establish precise causal gains.

The earlier 900-tick SO pair observed 0.986 → 0.983×, with 14 duplicants retained in both. It established no useful cache gain or meaningful regression. These historical results remain separate from the completed fresh SO comparison above.

Historical mean Unity-frame times were 47.1, 43.0, 51.5 and 53.0 ms for the base control, caches, numerical options and full combination. Faster simulation did not establish smoother input.

Why sustained, smooth 3× is still unproven

At 3×, each 0.2-game-second owner tick has a 66.7 ms wall-time budget. The fresh candidate replay still averages 85.6 ms before native/game overhead. The observed base live pair remains well below 3×.

The historical numerical combination reached 50.3 ms natively, but changed the trajectory, and native handoff, publication and game work still need time. SO needs work on repeated substeps and transport. This budget is not a combined-speed forecast.

03 / Historical experiments · 06 Nov

Keep exactness and numerical
tradeoffs separate.

The 6 November numerical and overlap experiments changed when data was read or how the fluid equations were solved. They remain separate from the current exact candidate; numerical defaults are unchanged and extra overlap is not adopted.

Redesign before use

Additional overlap exposes stale state.

The game thread and owner solver already overlap. The prototype overlaps additional native work with the solver using an older publication, adding 0.2 game seconds of lag.

Short runs observed +14.6% base throughput and +7.6% SO throughput. Focused synthetic controls show that the prototype can disagree about mass and skip heat. Passing the owner-only ledger does not catch these failures.

Synthetic counterexamples

0.25 kgFreeze mass discrepancy
0.15 kgWithdrawal shortfall
4,000 JHeat captured but skipped at an emptied cell

These counterexamples were demonstrated in focused tests. They are not claims of corruption observed in the large-colony runs.

Explicit numerical choices

Multigrid and tiny-liquid detail change the trajectory.

Both rows include the exact parcel caches. Differences are measured after 600 game seconds against the unchanged algorithm, using the same requested inputs. This is algorithm deviation, not physical ground truth.

The 1 mL setting suppresses interface sharpening for tiny liquid fractions or remaining voids in a 1 m³ cell. Constituent mass and heat remain in the simulation.

Multigrid

65.962 ms / owner tick

Temperature RMS / max difference
3.719 / 38.868 K
Liquid-volume L1 difference
0.5734 m³
Largest single-cell liquid difference
0.1725 m³
Gas-cell constituent L1
1.0995%

Multigrid + 1 mL interface detail

50.321 ms / owner tick

Temperature RMS / max difference
2.852 / 136.063 K
Liquid-volume L1 difference
9.9800 m³
Largest single-cell liquid difference
0.8448 m³
Gas-cell constituent L1
1.0347%

Temperature compares populated cells. The 136 K maximum is in a cell with about 3 g remaining; for gas above 100 g, that configuration’s maximum is 49.143 K. L1 is the sum of absolute differences. These liquid changes reflect redistribution, rather than lost mass.

Mass and energy conservation close, wall masks match, and no negative or nonfinite values appear. Those checks do not make the local temperature and liquid differences negligible. Keep these as explicit tradeoffs for gameplay review; keep the selected 1 g thin-gas-drag default.

04 / Completed follow-up · 07 Nov

Short pilots.
No further adoption.

Controls use the landed 40a1465 runtime. Base pilots cover 600 ticks / 120 game seconds; SO pilots cover 450 ticks / 90 game seconds. Each run excludes 50 warmup samples and uses 12 workers under the project CPU locks.

These fixed-input native pilots are separate from the qualified full-cycle and live-game comparisons above. No further runtime prototype was adopted.

Research complete · unadopted

Download follow-up data

Material-table reuse

Less transfer work. A small, uncertain total.

Base · eight runs
Mean owner tick
72.896 → 72.433 ms
Mean transfer stage
6.337 → 5.623 ms
Mean peak replay RSS
4,277.76 → 4,237.69 MiB
SO · four runs
Mean owner tick
153.523 → 150.162 ms
Mean transfer stage
11.516 → 10.224 ms
Mean peak replay RSS
1,012.80 → 1,024.65 MiB

Transfer work fell about 11% in both colonies. Across all eight base runs, owner time fell only 0.64%, with overlapping ranges. SO owner time fell 2.19%, but flow timings also varied despite unchanged flow arithmetic. The whole observed difference cannot be credited to the cache.

Control → prototype. Replay RSS includes the complete parsed journals, not game memory. The mixed peaks establish no memory saving. No further live-game gain is proven.

Run order, spread and cache mechanism

The first base ABBA comparison went the other way: 72.530 → 73.719 ms (+1.64%). Reverse-order confirmation changed the direction. All eight runs contribute four runs and 2,200 warmed samples per side. Control means range 70.877–74.183 ms; prototype means range 70.578–73.881 ms.

Base transfers fell 11.28%; projection fell 2.245 → 2.100 ms. SO transfers fell 11.22%; flow changed 136.141 → 134.159 ms without a flow arithmetic change.

The prototype keeps a derived material table per thread, keyed by immutable species definitions, EOS and liquid settings. Retaining the registry and EOS owners prevents an address reused by another object from becoming a false cache hit. This prototype remains available for possible later qualification, rather than being integrated.

Remap scratch capacity

No useful large-colony gain.

Base · four runs
Mean owner tick
72.132 → 72.292 ms
Owner time change
+0.22%
Mean peak replay RSS
4,266.52 → 4,311.82 MiB
SO · four runs
Mean owner tick
152.795 → 155.376 ms
Owner time change
+1.69%
Mean peak replay RSS
1,011.60 → 1,003.69 MiB

Retaining remap work-array capacity did not establish a colony gain or consistent memory saving. It is not integrated.

Synthetic result and retained SO variation

The six-mode synthetic operation benchmark averaged 0.16340 → 0.15872 ms (−2.86%), with overlapping ranges; synthetic-process RSS rose 6.496 → 6.922 MiB. The prototype reuses mass, flux, swept-volume, clock, stamp and work-list capacity, rewriting every logical entry before use.

The SO prototype means were 150.840 and 159.912 ms, versus controls at 151.909 and 153.681 ms. Both prototype runs remain in the total. The small synthetic saving did not carry through to the colony pilots.

Presentation opportunity · diagnostic only

Unchanged readings are not yet reused pixels.

Whole-colony positive-mass readings after warmup
Unchanged dataBaseSO
Cell readings58.23%79.18%
64-cell groups31.88%67.54%

These are whole-colony opportunities, not viewport hit rates, actual pixel reuse, allocation savings or FPS gains. Native publication already reuses unchanged readings and blocks; managed reading buffers are already pooled. Next, measure visible texture work and the cost of validating reuse across publications.

What was compared and what reuse must invalidate

The diagnostic compares bit patterns of all six scalar fields and ordered constituent species, masses and partial volumes, ignoring packed array offsets. A group contains 64 consecutive public cell IDs and is unchanged only if both membership and every reading match.

The mean positive-mass reading counts were 23,225.7 on base and 53,099.2 on SO, across 1,290 and 2,060 groups containing readings. The diagnostic’s extra copies were excluded from performance comparisons.

Cross-publication reuse must account for viewport use, ownership, passives, catalogue/model changes, load/reset and expired buffer leases. The current compact texture cache is invalidated when a buffer receives a new lease.

Heat projection: an upper-opportunity model, not a game gain

A projection-only model uses 2,424 actual energy-only parcel balances. At the maximum 13 recipients, recomputing versus remembering projection costs 0.78324 → 0.07540 ms per inventory. At one recipient, it costs 0.06885 → 0.06954 ms. Each measurement uses 200 inventories in ABBA order, with identical result checksums within each recipient count.

The roughly 0.71 ms upper opportunity assumes every balance visits every nonempty recipient; production may skip empty cells or stop sooner. This operation model includes an opaque function-call cost. It is not an observed owner or game gain, and no projected-energy cache was adopted. Destination searches already run once per source/radius key within a pass.

Follow-up verification scope

All 20 timed replays and both reading probes reproduce their control endpoint bytes. Relative mass/energy errors match within each cohort: 8.974e−16 / 5.714e−17 on base and 5.503e−15 / 2.201e−15 on SO. These are endpoint and ledger checks, not every intermediate checkpoint or a claim of physical ground truth.

Both prototypes passed the full game-kernel control executable, including worker-count and cold-continuation cases. The material cache also checked complete readings and copied/in-place transfers while alternating registries, EOS and liquid settings. Remap controls retained their pinned outputs and error/recovery checks. No existing gate input or bound changed.

The follow-up prototypes have not completed the full 93-test suite, all 88 diagnostic comparisons, 15 Linux batches, Windows checks or fresh live-game pairs. Those production qualification results above apply only to the landed 40a1465 runtime. Neither prototype was included in main; documentation commit abbbece records this completed research.

05 / Where to spend the work

Follow the remaining
critical path.

Fluid calculation takes roughly 86–89% of owner time in the follow-up. Focus on base pressure/interface work and the SO region’s repeated accepted transport.

The completed pilots add no adopted runtime change. The next steps below have no established further live-game gain.

  1. Rebuild main and playtest on Windows

    Keep the qualified parcel caches plus const reads from runtime commit 40a1465. Current main also contains the completed research documentation in abbbece. Actual Windows gameplay, performance and responsiveness remain for the user’s rebuild/playtest.

    Ready
  2. Target base pressure and interface work

    The large interface cluster has ordering dependencies. Investigate independent work using complete read/write footprints, including neighbor reads, while preserving face order and proving equivalent owner bytes.

    Next
  3. Reduce SO accepted-transport cost

    Repeated accepted transport remains expensive even if the first rejected trial gets cheaper. Pressure and implicit thin-gas drag depend on trial duration. Keep the 1 g drag, fixed physics and gates unchanged; pressure/transport subcycling remains numerical research.

    Next
  4. Measure visible texture reuse

    Profile viewport work and invalidation across publications before building another cache. The measured unchanged-reading percentages do not establish texture hits or pixel reuse, and existing native reuse and managed buffer pools must not be counted again as new work.

    Research
  5. Keep smaller transfer ideas in proportion

    Ordinary transfers already use an edit journal. Moving-parcel admission/retry staging must include caller receipt, energy and wire checks to preserve atomic refusal and immutable publications. Prior samples show about two accepted retries per frame, so the remaining private state copy is not established as the main bottleneck.

    Pipe heat updates already share immutable mass/passive arrays. Less repeated validation is a possible small CPU optimization, not an array-allocation elimination. No new managed-allocation or GC reduction is established.

    Unmeasured
Earlier diagnostic hotspots and concurrency limits

In one earlier industrial-base diagnostic frame, pressure takes 27.57 ms, interface correction 16.05 ms and transport 4.32 ms. In one SO vented-region frame, pressure takes 61.38 ms and transport 69.26 ms, versus 2.56 ms for interface work. These are explanatory samples, not whole-cycle averages.

Native handoff averages about 13.38 ms for UpdateData, plus 0.90 ms shadow writing, 1.17 ms contact capture and 1.42 ms game copying. Process/next waits are nested owner waits and must not be counted again as independent work.

Managed diagnostic timings point to texture updates and publication/receipt handling. Allocation-counter validation failed, so heap-growth readings are proxies, not exact allocated bytes; parent and child timings overlap.

Three additional exact surface caches produced no established extra full-cycle speedup. Lower worker counts may help CPU/memory budgets, but showed no reliable speed advantage. The GPU route remains closed by the project’s existing decision.

Game-thread/owner overlap already exists. The remaining positive native-frame fence orders messages, shadow writes, native contacts and paired heat capture. Removing it remains unsafe under the earlier contact/heat controls. Further exact overlap needs independent native jobs or owner-confirmed contact transactions, rather than another wait-removal switch.

The first flow proposal resets to dt / parts on each advance, and sized proposals carry between flow parts rather than owner ticks. Reusing the previous tick’s interval changes accepted partitions and needs a cold-continuation design; scaling a prior swept-volume ratio does not guarantee that another trial passes.

06 / Evidence & limits

Linux checks passed.
Windows playtest next.

The production qualification shown here applies to the runtime changes in 40a1465, ready for the user’s Windows rebuild. The completed follow-up pilots remain unadopted and have not repeated that full qualification. Actual Windows gameplay and performance remain to be tested.

93/93Native tests passed
66/66Linux scenarios passed
2Colony workloads

All 15 Linux batches and the strict unchanged-input/bound checker passed. Managed, Python and integration suites also passed. Wine controls do not qualify the Windows game; extra overlap remains unadopted.

Benchmark setup

Industrial base: prepared 32-duplicant benchmark with 1,474 building/floor/wire/conduit objects and 34,441 owned cells. It was instantly prepared, rather than played from cycle 1.

Spaced Out!: unchanged 14-duplicant stress save with 1,147 such objects and about 67,857 owned cells, including a compact base venting toward near vacuum.

Host: Linux, Ryzen 9 5900X (12 physical cores / 24 threads), about 60 GiB RAM and RTX 5090. The game logged a 640 × 480 window. Windows performance remains unmeasured.

Timing and exactness controls

Full native replays use the same initial state, the same 3,000 requested boundary inputs, 12 workers and fixed CPU affinity. Timing excludes the first 150 ticks. Four runs alternate unchanged/cached/cached/unchanged to reduce ordering bias.

Live runs request game speed 3. Reported throughput includes simulation startup and excludes loading before the first measured owner interval. Project locks control project workloads, not external host activity. External video work continued during the current base live pair. The historical live cohort also had background host activity.

Short SO comparisons use their own 900-tick controls because the vented region settles over a full cycle. Native replay, live game, and managed diagnostic timings have different scopes and must not be added together indiscriminately.

Main integration and Windows playtest

All 15 Linux batches / 66 scenarios and the strict unchanged-input/bound checker passed. Both fresh live pairs, native ABBA and the SO follow-up are complete. All 88 old/new diagnostics match with timing fields masked; 8 nonzero baseline diagnoses remain unchanged. Both Windows DLLs cross-built and focused Wine controls passed. Main commit 40a1465 contains the exact changes; Windows OS/game qualification remains for the user’s rebuild/playtest. No test inputs, grids or acceptance bounds were changed.

Additional safe overlap requires owner-confirmed mass/phase receipts, heat reconciliation, a native-frame ownership snapshot, and save/load/topology fencing. The removed-wait prototype is not ready to adopt.

Public evidence and provenance

This page distinguishes the qualified 40a1465 runtime comparison, the completed follow-up pilots documented in abbbece, and historical 6 November numerical/overlap experiments. Follow-up pilots, reading diagnostics and operation models are labeled separately from full-cycle native replay and live-game timing.

Only aggregate findings and original explanatory text are published here. Research inputs and captures remain private.

Download public aggregate data