FLIGHT MANUAL / 09 · SUPPORT

Performance

KMS performance work removes avoidable CPU, allocation, logging, and I/O cost before asking you to lower visual quality.

Faster loading

Keep KSP and its caches on a fast drive, reuse valid ModuleManager and Burst caches, avoid duplicate assemblies, and stop tools from rescanning immutable assets. A cache is reused only when its inputs and version fingerprints match.

Large-vessel stability

Physics, PartModules, UI polling, reflection, network graph updates, and log spam can all scale with part count. KMS budgets update rates and recomputes only dirty graph regions; operator dashboards use bounded snapshots instead of per-widget game queries.

Diagnose jitter

  1. Record scene, vessel part count, frame rate, physics delta time, and time-warp state.
  2. Compare CPU main-thread time with GPU frame time.
  3. Check KSP.log for repeated per-frame warnings or exceptions.
  4. Disable only the implicated subsystem in a copied profile.
  5. Retest the same craft and camera view before changing visual quality.

Visual quality

The full Spectra/EVE/Scatterer profile is the reference. Lower profiles are diagnostic tools or hardware accommodations, not the first response to a CPU-side exception storm.

Memory and heap

KSP 1 is 64-bit and can address large memory, but allocation churn and garbage collection still cause stalls. KMS favors pooled buffers, stable collections, bounded telemetry payloads, and unloadable caches. It does not promise unsafe heap patches or fabricate RAM limits.

Establish a performance baseline

  1. Launch the same save into the same scene with the same camera and physics settings.
  2. Wait for background loading and graph rebuilds to settle.
  3. Record median and low-percentile frame time, garbage collections, managed memory, part count, and log growth for at least two minutes.
  4. Change one subsystem and repeat the identical capture.
  5. Keep the evidence with the build hash and installed receipt.

Subsystem budgets

Network topology, GNSS geometry, SCANsat summaries, browser snapshots, and UI rendering use explicit update budgets. Dirty events trigger recomputation; ordinary frames reuse stable results.

A budget overrun is measured and surfaced. KMS does not hide simulation backlog by slowing clocks, skipping physics, or reducing visual fidelity without an explicit profile choice.

Stability safeguards

Bounded queues, cancellation on scene changes, null-safe teardown, rate-limited logging, and main-thread ownership prevent background helpers from outliving KSP objects. Expensive integrations degrade independently instead of cascading through the whole flight loop.