WPlanner performance and persistence architecture
Authoritative topic-oriented contract for the R125–R130 Planner remediation: immutable GUI operations, bounded interval parallelism, vector transformation and deferred validated-segment persistence.
GUI and operation boundary
EphemGen() and PlotGen() construct immutable operations and submit them to the shared background QThread runner. The widget contains no QApplication.processEvents() and no direct heavy compute call. Progress travels through signals and elapsed time through QTimer.
One job per comet/apparition interval
Planner batches all requested epochs for one comet/apparition interval into one job. That job performs at most one forward and one backward integration, rather than integrating each requested midnight independently.
The contract is interval-count based: one comet × four midnights and one comet × 500 epochs are each one interval job.
Bounded process ownership
One operation owns at most one spawn process pool. Pool workers cannot create nested pools. Automatic reference scenarios use at most four workers, so 300 comet intervals remain 300 jobs routed through four workers rather than 300 independent process pools.
Vector frame transformation
Planner element batches use one vector Astropy frame-transform call. Per-row transformations are outside the protected production route.
Deferred persistent-segment service
Fitting, validation, compression and writing are deferred through a bounded single-worker service. A successfully computed ephemeris is valid before persistence finishes.
- Persistence failure cannot invalidate the ephemeris.
- Queue saturation cannot invalidate the ephemeris.
- Shutdown timeout cannot invalidate the ephemeris.
- Only later cache reuse is lost when persistence does not complete.
- Atomic validated writes prevent partial data from becoming trusted cache state.
Deterministic reference scenarios
| Scenario | Interval jobs | Automatic workers |
|---|---|---|
| One comet × four midnights | 1 | 1 |
| One comet × 500 epochs | 1 | 1 |
| Four comets × 300 epochs | 4 | 4 |
| 300 comets × four epochs | 300 | 4 |
cold interval: 1 integration
warm covered interval: 0 integrations
background persistence: drained successfullyWall time, CPU utilisation and RSS remain target-system diagnostics rather than portable release thresholds.
Scientific non-regression and widget isolation
R130 changes no DE440s dynamics, Cowell equations, DOP853 tolerances, date-aware element/apparition selection, light-time, topocentric geometry, provenance or Cancel semantics. WStack remains serial and does not use the Planner persistent-segment cache or Planner process workers.
Release gate, Markdown hygiene and QA
wplanner_performance_release_gate.py enforces the complete production routing. documentation_hygiene.py separately enforces a small topic-oriented Markdown set for CLEAN and QA archives; obsolete per-release Markdown trees must not be restored during future merges.
- R130 complete QA: 1767 passed, 8 skipped, 0 failed.
- Final gates: analysis, modal ephemeris, WPlanner performance, documentation hygiene and performance validation all PASS.
- R130 manifests: 342 QA files and 95 CLEAN files.
Target-system acceptance
The build environment lacked the complete production PyQt5, Astropy, jplephem, DE440s and representative 300-comet runtime. Record cold/warm timing for all reference scenarios, 1/2/4-worker utilisation, Cancel during integration and deferred persistence, peak RSS, cache size and numerical comparison with R129.