Performance Log 0.1.1 — Preview 2

Fixes for what the first recording from a real game showed. Still a preview: 0.1.0 has been played once (every patch applied, a 31 minute session ended in a normal exit), but these fixes have only been checked outside the game. See docs/TESTING.md for what the first run proved and what is still unproven.

What was wrong in 0.1.0, and is fixed

• The mod swapped its timing wrappers into the game's singleton arrays about four times every frame (488,601 swaps in 122,150 frames): the game keeps two singleton services alive and they alternate, and the mod remembered only one. That garbage and time were counted inside otherMs / otherKB. Each service is now wrapped once. In 0.1.0 recordings, distrust the allocation figures and the garbage-collection section; tools/perflog.py report now prints a KNOWN ISSUE line for each known defect of the version that made a recording.
• Files were held open, so zipping or copying a session folder while the game ran silently left out frames.csv, profile.csv, spikes.csv and events.csv. They are now opened, appended to and closed on each write, shared with readers, and retried if someone else holds them.
• Every singleton of the game itself was labelled with no mod ("unknown"). They are now game.
• workingMB was always 0 (Unity's Mono reports 0). It now asks Windows, and the header says where the figure comes from.
• Loading steps now record how much the managed heap grew during each one, in profile.csv, summary.md and the report. (The first recording's heap went from 54 MB to 1.7 GB while loading, and nothing said which steps did it.)
• LoadAll never ran was a false alarm (the counter was cleared when the session started in the middle of the load).
• Draw calls: Unity 6 has no Draw Calls Count, Batches Count or GC Allocated In Frame counter (checked against this game's UnityPlayer.dll). prDraw is now the sum of Unity 6's draw call counters.
• The allocation source line now says why the exact counter was not used, and the cost of a Harmony patch is measured after warming up.

Install

1. Close Timberborn. Extract PerformanceLog-0.1.1.zip into Documents\Timberborn\Mods, replacing 0.1.0. It contains one PerformanceLog folder.
2. It requires the Harmony mod (2.4.1 or newer) from the Steam Workshop. Requires Timberborn 1.1.2.4 or a compatible 1.1 build.
3. Enable Performance Log in the mod manager and restart. Play with the game in front (a game in the background is throttled and says little), and leave normally.
4. Give the newest session folder to Claude, or run python PerformanceLog\tools\perflog.py report <folder> (Python 3.8+). Each folder has a README.md that explains how to read it.

What to check on the first run

Open the frames.csv header: # capability|workingSet| should say from Windows, and at the end # capability-final|patchCalls|singleton wrappers put in place should be a handful, not hundreds of thousands. Details are in the checklist in docs/TESTING.md.

Verified before release

89 checks of the mod (core timing against a scripted clock; the game-facing parts against the game's real 1.1.2.4 assemblies) and 44 checks of the analysis tool. Each fix that can be checked outside the game has a check that fails without it.

SHA-256 of PerformanceLog-0.1.1.zip: 063CEFFD7739E2686801671A1E502B862A5F5D3EBB644028A4E5885D509F6026