[Campaign] ProcessSystem and ProcessModel performance roadmap

[EvenSol]

Purpose

Persistent profiling, benchmark, acceptance, and progress ledger for end-to-end ProcessSystem and multi-area ProcessModel performance. This campaign changes code only for a unique, measured process-layer bottleneck with a meaningful representative-workload benefit.

Current master at roadmap creation: c1cde6a1c47f.

Owned scope

• ProcessSystem execution preparation, strategy selection, graph/level orchestration, dirty-state traversal, nested modules, and repeated-run overhead;
• ProcessModel area scheduling, boundary-stream convergence, plan validation, recycle coordination, and diagnostics;
• process-layer allocation, cloning, serialization, result construction, and disabled logging/telemetry overhead;
• end-to-end attribution of flash, thermodynamic initialization, and physical-property work performed by process equipment;
• representative cold, repeated-unchanged, and nearby-state process execution.

Coordination and exclusions

Coordinate rather than duplicate:

• TP/stability/multiphase solver internals: #2937;
• column/tray solver internals: #2936;
• transient execution contracts and reservoir-to-market dynamics: #2911;
• TwoFluidPipe and conservative pipeline solvers: #2907, #2935, and focused candidate #2850;
• initialization-level call-site audits: #2698;
• optimizer algorithms and capacity/sensitivity semantics belong to Production Optimization.

This lane may measure those components inside a complete process, but it must hand an internal solver bottleneck to its owning roadmap unless the fix is strictly process-layer orchestration.

Frozen benchmark matrix

Every candidate must use current unmodified master and retain a minimal deterministic reproducer. Cover the applicable subset of:

1. Serial state-changing process: rich-gas SRK/classic feed through at least eight sequential heaters/coolers/separation/compression operations.
2. Wide independent process: multiple independent SRK trains exercising automatic optimized dispatch.
3. Multi-area process: at least four ProcessSystem areas with shared boundary streams, two or more outer convergence iterations, and both sparse and dense boundary diagnostics.
4. Recycle process: a deterministic recycle tear with recorded iteration count, convergence residual, mass closure, and repeat behavior.
5. Associating control: SRK-CPA gas/water or glycol-bearing process so a cubic-only improvement cannot hide CPA regressions.
6. Orchestration control: stable lightweight units where process-layer CPU/allocation remains observable separately from EOS work.

For each relevant workload exercise:

• cold first execution;
• repeated unchanged execution;
• nearby temperature, pressure, flow, or specification changes;
• deterministic repeat after convergence;
• direct concrete execution entry points when dispatcher behavior changes.

Measurement contract

• fixed JVM and heap; report JVM/OS/GC;
• warmed deterministic inputs with multiple alternating baseline/candidate fresh-JVM pairs;
• median and paired-win count; retain raw fork results;
• main-thread and relevant worker allocation where measurable;
• JFR/async-profiler or explicit work counters for dominant execution paths;
• count process iterations, equipment runs, flash calls, thermodynamic init levels, physical-property initialization, plan validations, clone/serialization events, and submitted tasks when applicable;
• report full-process wall time even when a kernel is faster;
• no wall-clock assertion in ordinary CI.

Engineering acceptance gates

A production optimization requires all applicable evidence:

• at least 5% median end-to-end gain on a representative state-changing ProcessSystem or ProcessModel workload, with a majority of paired wins; or at least 15% allocation reduction plus a measured operational GC/throughput benefit;
• no material regression in thermodynamics-dominated, CPA, genuinely parallel, or nearby-state controls;
• unchanged public API and serialized compatibility unless separately approved;
• deterministic repeated results and calculation-ID behavior;
• unchanged phase topology, convergence/fallback status, iteration acceptance, and diagnostics;
• total/component mass and energy balances at least as tight as baseline;
• thread safety, clone independence, and no static/shared mutable cache;
• focused regression plus proportionate broader process tests;
• documentation-impact assessment and repository publication gates.

A kernel-only improvement without representative end-to-end benefit is evidence, not authorization for a PR.

Verified merged ledger

#2687 — avoid duplicate run preparation

Merged as 1e35232218b6. Warm optimized-process medians improved 23.7–35.0%, and a four-area lightweight ProcessModel improved 25.6%; thermodynamics-dominated sequential execution showed no reliable change. Nearby-point results were bit-identical.

#2902 — skip redundant nested active-state scan

Merged process-layer scan removal. A 500-stable-unit workload improved 4.54% (6/7 pairs); one-area ProcessModel improvement was noise-level, so no broad model claim was made.

#2904 — avoid dataflow scheduler for serial flowsheets

Merged as 152e9b76badd. A state-changing serial rich-gas chain improved 6.63% (6/7 pairs) with identical checksum, zero mass residual, phase count, and outlet pressure; genuinely parallel and multi-area controls were noise-level.

#2924 — reuse area plan in convergence diagnostics

Merged as 66a866f1e2e8. Direct diagnostics improved 32.5–85.7%; the full 10-area/900-boundary-stream ProcessModel improved 27.9% with identical convergence work and checksum. The thermodynamic control was noise-level.

#2929 — reduce convergence-diagnostic allocation

Merged as 31d0d9009c37. Repeated 900/4,500-stream diagnostics reduced allocation by 13.8–15.8% and runtime by 1.1–14.3%, preserving exact cardinality and checksum.

Coordinated flash evidence

#2930 merged as c1cde6a1c47f and is ledgered in TP-flash roadmap #2937. Its accepted raw-coefficient cache improved the beta-objective kernel 25.6–40.0% while preserving bit-identical derivatives; complete-flash improvement was only 0.47%, so no robust end-to-end claim was made.

#2963 — restore evidence-qualified equipment initialization

Merged as f604a089d2a8 after #2953 changed Compressor, Pump, and Recycle initialization without clearing the roadmap's representative-benefit gate. Exact-source A/B showed the four-stage Pump ProcessSystem 2.48% slower (2/7 wins), the three-stage SRK compressor train 1.05% slower by absolute medians, and only a kernel-level Recycle gain without convergence evidence. #2963 restored the qualified calls and added focused normal/low-flow Pump and Recycle guards. Its exact head bcca19e20368 passed PaperLab, pre-commit, an empty final Spotless patch, CodeQL, Javadocs, the Linux/Windows Java matrix, and all four slow-test shards; no reviews or unresolved threads remained. Public API, serialization, calculation identity, balances, phase behavior, and numerical results were unchanged.

Active increment

No Process Performance implementation PR is active.

Next dependency-ready investigation

Profile current master across the frozen matrix and attribute complete-run work before editing. The first ranked question is whether a process execution performs duplicate equipment runs, flashes, thermodynamic initialization, or initProperties() for the same accepted calculation state during:

• unchanged repeated execution;
• one nearby feed/specification change;
• one multi-area convergence iteration;
• one recycle convergence iteration.

Instrument counts locally to the benchmark or use JFR; do not add public telemetry merely to profile. Cross-reference every high-level initialization candidate with #2698 and every flash-internal candidate with #2937.

Stop without a PR if the dominant work is required physics, already owned elsewhere, or no unique process-layer change clears the end-to-end acceptance gate. Record the call/work distribution and next ranked hypothesis here.

[EvenSol]

Active PR #2953 audit — representative performance gate not met (2026-08-11)

Current master/base: 12b0e2fab3c4. Active head: 85f675e6cb61.

#2953 bulk-replaces level-3 initialization with level 2 at Compressor inlet, Pump inlet/low-flow, and Recycle enthalpy mixing. The Compressor and Pump standard-run changes duplicate rejected #2698 audits (compressor evidence, pump evidence).

Independent exact-source A/B used OpenJDK 17, fixed 1 GiB heap/G1, alternating fresh JVM order, current source overlays, state-changing nearby temperatures, and exact accumulated checksums.

• Four-stage liquid Pump ProcessSystem, seven pairs, 200 warmups + 3,000 measured runs/fork, one active processor: baseline median 0.669233 ms/run, candidate 0.685810 ms/run (2.48% slower); candidate faster 2/7; checksum exactly 1015233.43279179.
• Three-stage SRK rich-gas compression ProcessSystem, seven pairs: absolute medians 18.635178 -> 18.829971 ms/run (1.05% slower); candidate faster 5/7, but median paired improvement only about 2.7%, below the 5% gate; checksum exactly 27909.6931699966.
• SRK-CPA control, three pairs: 137.902903 -> 137.009158 ms/run (noise-level); checksum exactly 27918.2212327944.
• Direct Pump call: 0.541808 -> 0.475350 ms/run (12.27% faster, 6/7), but the representative Pump process does not retain that kernel gain.
• Recycle enthalpy kernel: 0.043608 -> 0.035543 ms/call (18.49% faster, 7/7), but no recycle-containing end-to-end process/convergence evidence exists.

Decision: requested changes on #2953. Do not open a competing Process Performance PR. Compressor/Pump should be removed unless a materially different profiler-backed workload overturns both prior and current evidence. Recycle may remain only after representative recycle ProcessSystem/ProcessModel measurement, convergence/iteration counters, focused initialization regression, nearby-state/CPA/balance/phase/repeatability/clone/serialization controls, and a documentation-impact assessment.

Local exact changed classes and current ProcessSystem compiled successfully. Maven could not resolve maven-enforcer-plugin:3.6.3 because the canonical Maven Central host failed DNS resolution; no Maven test is claimed. PR CI is the follow-up validator.

Documentation impact: none — no repository source, API, result, unit, default, documentation, branch, or campaign PR was changed by this audit.

[EvenSol]

Active process-performance correction: draft PR #2963

Draft PR #2963 is the single active implementation for this roadmap at head bcca19e203686814940cd262779ee1632b458594, based on master e8991c41163018299c0eacf8fef96e378a8fca72.

It corrects merged #2953 by restoring the four pre-change init(3) calls in Compressor, normal/low-flow Pump, and Recycle. The decision is evidence-based:

• four-stage Pump ProcessSystem: perf(process): replace redundant init(3) calls with init(2) in equipment run loops #2953 2.48% slower (0.669233 -> 0.685810 ms/run; 2/7 wins; exact checksum unchanged);
• prior six-stage audit: 8.21% wall and 8.48% CPU regression;
• three-stage SRK compressor: perf(process): replace redundant init(3) calls with init(2) in equipment run loops #2953 1.05% slower by absolute medians;
• CPA control: noise-level difference;
• Recycle's 18.49% kernel-only gain had no representative convergence/iteration/nearby-state qualification.

The PR removes the non-discriminating init2 smoke test and adds focused normal-Pump, low-flow-Pump, and Recycle initialization guards. Existing multiphase-CPA compressor coverage remains the behavioral control.

VALIDATION PENDING FULL CI: the first hosted Spotless run produced one reviewed Javadoc-only patch, applied exactly in bcca19e. On the final head, the Spotless artifact is empty; PaperLab, pre-commit, Spotless, CodeQL, Javadoc, and all four Java 21 slow-test shards have passed. The complete Java 21 Linux and Windows jobs remain in progress. The branch is mergeable, conflict-free, and current with master; there are no reviews or unresolved threads.

Local documentation search passed; local Spotless and Maven tests were blocked by missing isolated Maven plugins and are not claimed as passing.

Documentation impact: none; this restores prior internal behavior without public API, unit, default, configuration, serialization, or recommended-usage changes.

[EvenSol]

2026-08-13 profiling — active-state preparation candidate rejected

Profiled exact master 6481aaf714c5f8d6c3392abfb7c0da3ce2c29a80 and tested one bounded process-layer candidate: in resetActiveStates(), call needRecalculation() only for inactive auto-bypassed units, because active units are queried by the concrete scheduler. A focused counter regression proved the intended work reduction, while the existing low-flow reactivation regression still passed.

Environment and method

• OpenJDK 17.0.19, Linux 6.18.35, G1, -XX:ActiveProcessorCount=2, fixed 768 MiB heap for the representative process.
• Exact current sources were compiled with the JDK compiler module; Maven dependency resolution was unavailable because repo.maven.apache.org DNS failed.
• Alternating fresh-JVM baseline/candidate order.
• Representative state-changing case: classic-SRK rich gas; feed + two heaters + two separators + two compressors + two coolers + one valve; feed flow alternated 79,990/80,010 kg/h so all 10 units ran once per measured solve; 50 warmups and 150 measured solves per fork.
• Orchestration control: 200 active lightweight shared-feed units; 200 warmups and 20,000 unchanged solves per fork.

Results

Representative state-changing raw ms/run, baseline/candidate:

44.525/28.739, 31.450/75.360, 29.337/45.884, 37.790/47.819, 50.776/47.680, 34.512/51.588, 53.914/44.502

• baseline median: 37.790 ms/run
• candidate median: 47.680 ms/run
• candidate change: 26.17% slower
• paired wins: 3/7
• final outlet checksum: exactly 55804.521912873950 for both variants in every fork

The lightweight control did show the isolated mechanism: needRecalculation() queries fell from 400 to 200/run; median improved 22.384 -> 19.313 µs/run (13.72%, 9/10 wins). This kernel/control gain does not authorize a production change because the representative state-changing workload failed both the 5% and majority-win gates. The candidate and counter test were reverted; the checkout is clean. No branch, commit, issue, or PR was created.

Work distribution

Built-in equipment profiling on one fully propagated nearby-flow solve recorded exactly one call for each of all 10 units; no duplicate equipment run was found. A measurement-only JFR (300 nearby solves, 1,171 execution samples) was dominated by required thermodynamic paths: TP-flash appeared in 1,085 sample stacks, PH-flash in 455, PS-flash in 130, with leading leaves in classic-SRK calcAi, EOS molar-volume, calcB, and PhaseEos.init. Those are solver/initialization-owned paths (#2937/#2698), not a unique process-layer duplication.

Next ranked investigation

Move exact work counters to the four-area convergence and recycle cases, where the same accepted state can be revisited across outer iterations. Count equipment runs plus flash/init/property-init calls per accepted area/recycle iteration before considering any cache or scheduling change.

Documentation impact: none — no repository change was retained. Publication gates were not applicable; python devtools/run_spotless.py apply could not run in this read-only Maven-home environment, and no diff was published.

[EvenSol]

Active increment — draft PR #2991 (2026-08-13)

Draft PR #2991 is the single active Process Performance implementation at exact head e7d1c5a786912d5d053e72192b58ddb22cac58c2, based on master e0cb19cf1b1cf4c4408c7ec113037661c674f2a6.

Measured bottleneck

Repeated ProcessModel.run() reset and reapplied automatic flow-noise thresholds after the first area pass. That set autoTuningChanged and disabled incremental scheduling for the confirmation pass. An empty changed-boundary set also mapped to null (“run all areas”). The four-area inlet/recycle/compression/delivery workload therefore ran every area twice even for an accepted unchanged state.

#2991 pre-applies tuning only for a previously converged model with populated internal streams and no observable lifecycle hooks, then lets an empty dirty set execute as an empty confirmation pass. Cold and progress/event runs keep existing behavior.

A/B evidence

OpenJDK 17.0.19, Linux 6.18.35, G1, fixed 512 MiB heap, -XX:ActiveProcessorCount=2; eight warmups plus 20 measurements per fresh JVM; seven alternating baseline/candidate pairs.

Unchanged repeated fork medians (ms), baseline/candidate:

121.426/27.465, 107.205/47.219, 100.757/28.200, 55.298/40.962, 68.002/58.630, 68.992/49.186, 83.127/42.310

• median of fork medians: 83.127 → 42.310 ms (49.10% faster)
• paired wins: 7/7
• area executions per 20 solves: 160 → 80

Nearby 50,000/50,500 kg/h fork medians (ms), baseline/candidate:

71.070/58.647, 82.990/134.526, 126.711/143.662, 211.426/76.401, 136.028/67.585, 67.716/102.261, 73.777/63.542

• median of fork medians: 82.990 → 76.401 ms (7.94% faster)
• paired wins: 4/7
• area executions: 160 → 140

A genuinely parallel four-area control reduced area executions 160 → 80 and outer iterations 40 → 20, was faster in 3/3 alternating pairs, and retained exact checksum 26654000.000000000000. One SRK-CPA gas/water diagnostic pair reduced area executions 160 → 80 with exact checksum sum 1407041656.9761167; its timing is a control, not a statistical claim.

Cold/nearby/stable accumulated checksums were exact between variants. Both had zero non-converged runs, recycle iterations 2, zero recycle flow/temperature residual, and zero model mass-closure error.

Validation and scope

• focused plus proportionate related JUnit tests: 77/77 passed
• modified main/test sources compiled directly
• Spotless apply: exit 0; second apply: exit 0
• Spotless check: exit 0
• documentation search: exit 0
• diff check: exit 0
• pre-commit executable unavailable
• full hosted CI pending

VALIDATION PENDING CI

Documentation impact: none — internal scheduling realization only; no API, option, unit, default, serialized field, thermodynamic result, or recommended workflow changes.

The autonomous portfolio is now at the user-authorized five-PR ceiling (#2632, #2987, #2989, #2990, #2991). Do not open another campaign PR until capacity is released.

[EvenSol]

Verified merged increment: PR #2991 — incremental repeat scheduling

#2991 merged into master as 231fc66f42a5. Current master is 049466d1d583, one unrelated dynamics commit ahead; comparison confirms the performance merge is its ancestor.

Verified exact-head gates for e7d1c5a78691:

• PaperLab Replication Gate: success;
• Spotless format patch: success;
• Pre-commit checks: success;
• CodeQL Security Analysis: success;
• full build, test, and Javadoc: success;
• mergeable/conflict-free before merge;
• no reviews, requested changes, comments, or review threads.

Representative evidence retained from the accepted PR:

• unchanged repeated four-area SRK model: 83.127 → 42.310 ms, 49.10% faster, 7/7 paired wins, area executions 160 → 80;
• nearby 50,000/50,500 kg/h model: 82.990 → 76.401 ms, 7.94% faster, 4/7 wins, area executions 160 → 140;
• parallel control: area executions 160 → 80, exact checksum unchanged;
• SRK-CPA control: area executions 160 → 80, exact checksum unchanged;
• focused/proportionate local tests: 77/77;
• exact stable/nearby checksums, recycle residuals, convergence status, and mass closure were unchanged.

Documentation impact: none — the merged change only realizes the existing incremental execution contract internally and changes no API, option, unit, default, serialization shape, or recommended workflow.

The Process Performance lane has no active implementation PR after this merge. The next run should reprofile current master across the frozen matrix and select a new tranche only if a unique process-layer bottleneck clears the representative end-to-end gate; solver-owned work remains excluded.

[EvenSol]

Merged increment — PR #3010: reuse unchanged boundary diagnostics

Merged: #3010
Exact reviewed head: e030a127e20d1f88001fa77cb621f10fa6533796
Merge commit: c4f557b2e03cb9a3feb7ca9c7d830b6b8f5480e2

Profiling isolated repeated immutable BoundaryStreamError allocation in full dense multi-area convergence. The merged implementation is instance-local and transient, keyed by stream identity, and reuses a diagnostic only after bit-exact numerical plus name/producer matching.

Evidence on OpenJDK 17.0.19, Linux, G1, 768 MiB, two active processors, seven alternating fresh-JVM pairs (100 warmups + 750 measured per fork):

• stable 10-area/900-boundary ProcessModel: 3.406846 -> 2.809589 ms median, 17.53% faster, 6/7 wins; ~394,118 -> ~311,756 B/run, 20.9% less allocation;
• nearby alternating-flow model: 3.310199 -> 3.030751 ms, 8.44% faster, 6/7 wins; ~396,912 -> ~314,953 B/run, 20.65% less allocation;
• exact stable/nearby checksums, two observations, 900 diagnostics, and area-run counts were unchanged.

Controls retained exact outcomes: SRK stable 760710.468859696, SRK nearby 764372.3062039946, SRK-CPA 204181.82060473916, and no-boundary 20000.0; topology, convergence, nonconvergence count, and zero mass error were unchanged. The focused class passed 14/14 locally.

The nullable-map review was accepted with Collections.emptyMap(); its only inline thread is resolved. On the exact head, Spotless, pre-commit/documentation search, PaperLab, CodeQL, Javadocs, Ubuntu/Windows fast tests, and all four slow-test shards completed successfully. The final diff contained only ProcessModel.java and ProcessModelExecutionOptimizationTest.java.

Documentation impact: none — internal immutable-diagnostic allocation reuse; public API, values, ordering, units, configuration, serialization, and usage are unchanged.

Current master dc3d907586a895dbac15db85643f4496be1645e9 retains merge commit c4f557b2e03cb. No Process Performance implementation PR is active. The next dependency-ready work remains exact work-counter profiling across multi-area and recycle iterations; do not publish another implementation while the autonomous campaign portfolio is at its three-PR limit.

[EvenSol]

2026-08-15 profiling — qualified recycle re-confirmation tranche (publication deferred)

Exact profiled master: 9a371fb1448bb713990072c2d3d4a291c71dab68.

Bottleneck

A previously converged recycle process still starts every new run() as an unconfirmed convergence cycle. RecycleController.init() resets the accepted iteration state, and the sequential/hybrid/progress loops enforce a two-iteration minimum. On a stable 80% gas recycle, exact built-in unit profiling therefore recorded two calls each to Mixer, Separator, Splitter, and Recycle on every unchanged run, despite zero flow, temperature, pressure, and composition residuals.

A measurement-only prototype carried prior acceptance into the first new recycle observation, but retained ordinary iteration whenever that observation changed. The prototype preserves the reported final iteration count by removing the internal seed after convergence. It touches only ProcessSystem loop termination and RecycleController accepted-state bookkeeping; no flash, EOS, equipment, or tolerance logic changes.

Representative A/B

Environment: OpenJDK 17.0.19, Linux, G1, fixed 768 MiB heap, -XX:ActiveProcessorCount=2; seven alternating baseline/candidate fresh-JVM pairs.

Stable SRK recycle, 50 warmups + 400 measured runs/fork:

• baseline median: 4.938900 ms/run
• candidate median: 2.145289 ms/run
• change: 56.57% faster, 7/7 paired wins
• main-thread allocation: 669,973 -> 378,004 B/run (43.58% less)
• Mixer/Separator/Splitter/Recycle: 2 -> 1 calls/run
• exact accumulated checksum: 20135968.802297734
• final recycle iterations: 2; zero residuals; 0 non-converged runs in both variants

Nearby alternating 50,000/50,500 kg/hr, 20 warmups + 100 measured runs/fork:

• baseline/candidate medians: 42.156144 / 43.811487 ms/run
• candidate change: 3.93% slower, but 4/7 paired wins and effectively identical allocation; treat as noise-level pending a longer qualification
• every process unit executed 36 times/run in both variants
• exact checksum 5062415.000000005, final iteration count 36, zero residuals, and convergence status were unchanged

Controls:

• cold SRK solve: exact checksum 50393.92200574459, 56 unit/recycle iterations, convergence, and residuals unchanged; single-fork timing is not used as evidence
• stable SRK-CPA gas/water: exact checksum 493296.79230167175, final iteration count 2, and zero residuals; one control pair reduced 211.23 -> 122.45 ms and 240.6 -> 132.6 MB/run by removing the same duplicate pass, but this is not a statistical timing claim
• Java 8 direct source compilation passed for both candidate classes
• focused existing RecycleAdaptiveAccelerationTest, RecycleControllerTest, and ProcessSystemExecutionPreparationTest: 30/30 passed
• the first prototype exposed an NPE for an unconfigured Recycle; the accepted local prototype now gates prior-state inspection on getIterations() > 1, and the full 30-test focused set passes

Full Maven validation was not run: the task-local Maven home worked, but canonical https://repo.maven.apache.org/maven2/ failed DNS while resolving maven-enforcer-plugin:3.6.3. No Maven result is claimed.

Decision and next acceptance work

This is a unique process-layer bottleneck and clears the representative benefit gate. Do not publish yet: four autonomous implementation PRs are open (#3027, #3031, #3032, #3033), above the scheduled-campaign skill's three-PR ceiling.

When capacity is available, the next single Process Performance PR should complete this same tranche with:

• focused regressions for unchanged accepted, nearby changed, cold, unconfigured, inactive/bypassed, multi-priority, adaptive/Wegstein, sequential, hybrid, and progress-listener paths;
• clone and serialization controls proving the transient accepted-state map cannot leak or change persisted form;
• representative SRK and CPA A/B reruns plus a longer nearby-state control;
• exact diagnostics, iteration count, calculation ID, mass/energy closure, phase topology, and deterministic repeat checks;
• direct Spotless, documentation-search, pre-commit/pre-push, and proportionate hosted CI.

Documentation impact: none for the measured direction. It changes only internal reuse of an already accepted recycle confirmation; public methods, configured tolerances, units, outputs, serialized fields, and recommended usage remain unchanged. No branch, commit, or PR was created.

---

2026-08-16 qualification update — safety gate strengthened

Current authoritative master is 9b57ac4d3df2654911c7031752912e20b7310947. Connector comparison from the profiled base confirms that no intervening commit changed ProcessSystem or RecycleController; the only newer files are TP-flash repair workflow/support artifacts.

A new process-level regression exposed an important edge before publication: a recycle that merely satisfies its configured tolerance can still move the process result measurably on its next observation. The candidate is therefore narrowed to reuse prior acceptance only when every stored flow, composition, temperature, and pressure residual is finite and within max(1e-12, configured tolerance * 1e-6). Ordinary tolerance-level convergence retains the legacy two physical confirmation passes. The original zero-residual SRK and CPA benchmark states still qualify for the measured duplicate-pass removal.

Local exact-source validation after that correction:

• Eclipse JDT compiler, Java 8 source/target: changed production classes and regression compiled successfully.
• Existing RecycleAdaptiveAccelerationTest, RecycleControllerTest, and ProcessSystemExecutionPreparationTest plus the new RecycleAcceptedStateReuseTest: 34/34 passed.
• New coverage proves: one physical confirmation only for effectively unchanged SRK states across sequential, hybrid, and progress paths; the same CPA behavior; two-pass fallback for ordinary tolerance-level convergence; changed-boundary iteration beyond two observations; nearby fresh-solve agreement in flow/temperature/pressure/phase topology; legacy reported iteration count 2; and calculation-ID propagation.
• The repository's exact Eclipse 4.35 formatter profile was applied directly to the three candidate files and a second pass produced identical SHA-256 hashes.
• The direct Maven-wrapper Spotless command was attempted from the source-only workspace but Eclipse P2 DNS resolution was unavailable. No Maven, repository-wide Spotless script, documentation-search, pre-commit, or hosted-CI result is claimed.

Published as draft PR #3041 at exact head c7a3f7a3a7eb, based on master c67c3765df113e1448ff7942744a58020d189cba. The user-set five-autonomous-PR ceiling leaves capacity for this single active #2939 implementation. VALIDATION PENDING CI; do not classify ready until exact-head hosted formatting, documentation, build/test/Javadoc, review-thread, mergeability, and final-diff gates pass.

Documentation impact: none — internal accepted-state reuse with no public API, tolerance/default, unit, output schema, serialization field, or recommended-usage change.

[EvenSol]

Verified merged increment — PR #3041 and follow-up #3050: reuse fully accepted recycle states

Performance implementation: #3041, merged as a0f17b3e4ba8.
Post-merge regression-contract repair: #3050, merged as ccf281d6a654.
Verified current master: 16e67be6bbbe; connector ancestry comparisons show both merge commits are retained with zero commits behind.

The merged process-layer optimization reuses a prior recycle observation only when all stored flow, composition, temperature, and pressure residuals are finite and within max(1e-12, configured tolerance * 1e-6). It removes the duplicate physical confirmation pass for effectively unchanged accepted SRK and SRK-CPA recycle states, while preserving the legacy two-pass behavior for ordinary tolerance-level convergence and for active-to-zero-flow collapse.

Accepted representative evidence from #3041:

• stable SRK recycle: 4.938900 -> 2.145289 ms/run, 56.57% faster, 7/7 paired wins;
• main-thread allocation: 669,973 -> 378,004 B/run, 43.58% less;
• Mixer/Separator/Splitter/Recycle calls: 2 -> 1 for the stable accepted state;
• exact stable checksum 20135968.802297734, final reported recycle iterations 2, zero residuals;
• nearby 50,000/50,500 kg/hr control retained 36 calls, checksum 5062415.000000005, iteration count 36, zero residuals, and convergence; no timing benefit claimed;
• cold SRK checksum 50393.92200574459 and 56 iterations unchanged;
• SRK-CPA checksum 493296.79230167175, final iteration count 2, and zero residuals unchanged.

The first full #3041 build exposed one test-contract failure after the production behavior had already preserved the required second upstream pass on recycle collapse: the deactivated Recycle itself is correctly skipped on that second pass. #3050 corrected the assertion to require two Mixer/Separator/Splitter calls and one Recycle call, while retaining the product-flow, solved-state, and externally reported iteration-count checks.

Exact-head verification for #3050 head 12e11aa88152:

• focused Java 8 source/target compile and four recycle/process suites: 35/35 passed;
• Spotless format workflow, pre-commit/documentation search, CodeQL, Java 21 Javadocs, Linux/Windows Java 21 tests, all four Ubuntu slow-test shards, and Linux/Windows Java 8 tests: all completed successfully;
• no reviews, requested changes, comments, or review threads on either PR;
• final scope remained the two production files plus focused regression in [AI-Assisted] perf(process): reuse fully accepted recycle states #3041, followed by the single assertion-only test repair in test(process): verify collapsed recycle confirmation path #3050.

Documentation impact: none — internal accepted-state reuse and a test-contract correction; no public API, configured tolerance/default, units, calculation outputs, serialization interface, or recommended usage changed.

The Process Performance lane has no active implementation PR. The next run should profile current master across the frozen matrix before selecting another tranche; no new implementation is authorized from static inspection alone.

[EvenSol]

2026-08-17 profiling — disabled lifecycle-event allocation rejected

Exact authoritative master: 0ef7b4c2ccc1. No Process Performance PR was active; the three open autonomous PRs belong to Column Solver, dynamics, and Engineering Diagrams.

Hypothesis

ProcessSystem defaults publishEvents to false, but sequential execution still constructs two ProcessEvent objects and generates their UUIDs before publishEvent(...) discards them. A measurement-only candidate guarded the sequential start/completion construction with if (publishEvents). Enabled-event behavior was unchanged.

Representative A/B

OpenJDK 17.0.19, Linux, G1, fixed 768 MiB heap, -XX:ActiveProcessorCount=2; seven alternating baseline/candidate fresh-JVM pairs; 100 warmups + 800 measured runs/fork.

Workload: state-changing SRK/classic rich gas, alternating 50,000/50,500 kg/hr, through one feed, eight sequential heaters/coolers, and two separators. ProcessSystem.run(UUID) used the legacy sequential entry point to isolate the two relevant event sites.

• baseline median: 2.761627 ms/run
• candidate median: 2.673274 ms/run
• median change: 3.20% faster
• paired wins: 3/7
• main-thread allocation median: 1,366,681 -> 1,366,512 B/run (0.012% less)
• exact accumulated checksum in every fork: 40490519.999999390000000

A separate profiled changed-flow run recorded exactly one call for the feed, every heater, and both separators. No duplicate process-unit execution was present.

A baseline JFR allocation profile attributed the dominant sampled allocation to thermodynamic/equipment internals: component cloning, physical-property mixing-rule array cloning, SRK calcA arrays, and Jama matrix/SVD arrays. Disabled ProcessEvent construction did not appear among the leading allocation sites. Those flash/EOS/property kernels remain outside this roadmap unless process-layer orchestration proves it invokes them redundantly.

Decision

Rejected: the result is below the 5% representative end-to-end gate, has a minority of paired wins, and provides no meaningful allocation reduction. The measurement-only source change was not retained; no branch, commit, issue, or PR was created.

Local validation used exact current process source with offline Maven compilation (BUILD SUCCESS) plus direct Eclipse compiler compilation of the measurement candidate and harness. No repository publication gates were needed because no repository change was retained.

Documentation impact: none — the candidate was discarded and no code or behavior changed.

Next ranked investigation: multi-area/recycle execution with explicit flash, property-initialization, and per-area work counters. Hand any dominant TP-flash/EOS kernel to #2937 unless a duplicate process-layer invocation is demonstrated.

[EvenSol]

Profiling checkpoint — flash/property work attribution; no implementation

Base: current master eb284675a029. The connected GitHub state showed no active Process Performance PR or overlapping open performance/benchmark PR before measurement.

Workload and counters

I compiled exact current ProcessSystem, ProcessModel, Stream, Heater/Cooler, Separator, Compressor, and ThrottlingValve sources as local overlays for a four-area, 12-unit rich-gas model (three shared boundary streams; two accepted outer iterations). The measurement-only counters were not proposed for production.

Per repeated model run:

control	TP flashes	full physical-property initializations	typed physical-property initializations
stable SRK	5	7	2
stable SRK-CPA	5	7	2
nearby SRK, alternating 50,000/50,500 kg/h feed	5	13	2

Caller attribution showed that all five TP flashes were state-producing work: four Heater.run calls and one feed Stream.run. Stable physical-property work was one stream initialization, four heater/cooler initializations, and compressor inlet/final property work. The nearby case added six Separator.finalizePhaseOutlet full-property builds, one for each non-empty phase outlet. Built-in unit profiling showed at most one call per registered unit in the last area pass; no repeated flash for the same accepted state was identified.

Rejected candidate

Separator.finalizePhaseOutlet calls init(3) immediately before initProperties() (which performs init(2) plus physical properties), so I tested a local candidate that removed only the preceding level-3 initialization.

Five alternating fresh-JVM pairs, each with 60 warmups and 240 nearby-state runs (OpenJDK 17.0.19, Linux x86_64, G1):

• baseline median: 9.139763 ms/run
• candidate median: 10.219872 ms/run (11.82% slower)
• candidate paired wins: 1/5
• main-thread allocation median: 4,572,055 -> 4,569,468 bytes/run (0.057% reduction)
• exact aggregate checksum: 9172467.674447922 in both variants
• exact final outlet: 36,984.557177414645 kg/h, 315.15 K, 100 bara, one phase
• convergence: two outer iterations; mass-closure error exactly 0 in both variants

The candidate therefore fails both the runtime and allocation gates; the apparent duplicate is not an evidence-qualified optimization and could also remove derivative state expected by downstream users.

Decision: no code change, branch, issue, or PR. The measured thermodynamic/property work is necessary at these call sites or belongs to the initialization-level audit in #2698. The next ranked process-layer question is allocation/clone attribution around state-changing separator phase-outlet construction before considering any call-site change.

Documentation impact: none — measurement-only local instrumentation and a rejected candidate; no repository behavior or API changed. Publication gates were not applicable because no repository commit or PR was created.

[EvenSol]

Profiling checkpoint — separator clone/allocation attribution; no implementation

Base: current authoritative master 44f705a90359. Exact GitHub blobs for ProcessSystem, ProcessModel, Stream, Separator, and the relevant thermodynamic system interfaces/implementation are byte-identical to the locally compiled measurement snapshot. No Process Performance PR is active. Six autonomous EvenSol implementation PRs are currently open, exceeding this campaign's five-PR publication cap, so this checkpoint is profiling-only.

Representative measured window

OpenJDK 17.0.19, Linux x86_64, G1, fixed 768 MiB heap, two active processors. The workload is the existing four-area, 12-unit rich-gas ProcessModel with three shared boundary streams and two accepted outer iterations. The nearby-state control alternates the SRK feed between 50,000 and 50,500 kg/h.

After 100 unrecorded warmups, JFR recorded only 300 measured runs:

• mean runtime: 11.665418 ms/run
• main-thread allocation: 4,571,176.4 bytes/run
• exact accumulated checksum: 11465584.593059951000
• exact final outlet: 36,984.557177414645 kg/h, 315.15 K, 100 bara, one phase
• convergence: two outer iterations; mass-closure error exactly 0

Clone attribution

Measurement-only call counters over ten nearby runs recorded 77.5 SystemThermo.clone() calls/run:

• flash-internal: Flash.findLowestGibbsEnergyPhase 35/run and TPmultiflash.stabilityAnalysis 17/run (52/run, about 67%); this is TP-flash kernel scope owned by [Campaign] TP-flash stability, multiphase equilibrium and performance roadmap #2937
• phase-output construction: phaseToSystem 4.5/run plus getEmptySystemClone 2.7/run (7.2/run, about 9.3%)
• direct equipment/state-isolation callers: the remainder, led by Mixer, Heater, Separator, Compressor, Stream, and ThrottlingValve

Measured-only JFR attribution agrees with the call counters. Separator phase-output clone paths represented 3.83% of total sampled allocation weight, or about 5.5% of process-attributed sampled allocation after excluding JFR/outside frames. Even perfect removal is therefore well below #2939's 15% allocation gate. Dominant process allocation was required valve/compressor flash work; dominant low-level sites were component/system cloning, stability analysis, EOS calcA arrays, and physical-property mixing-rule cloning.

The standard single-inlet separator also has two intentionally independent states: Mixer.run clones the inlet into the publicly observable mixer outlet returned by Separator.getFeedStream(), then Separator.run clones that outlet into its pressure-adjusted, phase-manipulated working system. Sharing those objects would make separator pressure drop/entrainment/phase work mutate the exposed feed state and would change public aliasing and repeated-run semantics. That is not a safe redundant-clone removal.

Decision

No candidate clears the material-benefit gate within process-layer ownership, and the only apparent extra clone cannot be removed without a compatibility change. No production change, branch, issue, or PR was created. The measurement-only counters/JFR harness are not proposed for the repository.

Documentation impact: none — profiling-only evidence; no API, behavior, units, serialization, or documentation changed. Repository publication gates were not applicable because no repository change was retained.

Next ranked process-layer work should move away from separator phase-output cloning. Flash-internal cloning remains with #2937; physical-property initialization-level changes remain with #2698.

[EvenSol]

2026-08-20 — multi-input dataflow dispatch verified merged

PR #3131 merged as c5e70bd4dcc5. The merge is retained in current master 06bd37614d4e; connector ancestry reports the merge commit 0 behind.

Measured bottleneck: runOptimized() forced every multi-input feed-forward graph through level barriers even though the cached dataflow plan already models all predecessors and shared-input groups.

Exact automatic-dispatch A/B on alternating fresh JVMs:

• balanced SRK mixer trains (44 units): 35.7% faster, 5/5 wins;
• imbalanced SRK mixer trains (40 units): 8.0% faster, 4/5 wins;
• imbalanced SRK-CPA mixer trains (40 units): 35.0% faster, 3/3 wins.

All fork checksums were bit-for-bit identical and solved=true. Focused Java 8-source compilation succeeded and 14/14 dispatcher, preparation, clone, SRK/CPA, nearby-state, repeated-run, mass/enthalpy/phase/composition, and concurrent-instance tests passed.

The exact feature head passed all applicable workflows: Java 8/21 Ubuntu/Windows build and tests, four Java 21 slow-test shards, Javadoc, CodeQL, Spotless, pre-commit, documentation search, and PaperLab. The final diff contained exactly the five intended ProcessSystem implementation, benchmark, regression, and documentation paths; no reviews or unresolved threads remained.

Documentation impact: updated. Both affected ProcessSystem execution guides now document the automatic dataflow selection and multi-input safety contract. APIs, serialized fields, numerical tolerances, thermodynamic kernels, phase behavior, and convergence logic remain unchanged.

[EvenSol]

2026-08-21 profiling — sparse dataflow task pruning rejected

Source: current ProcessSystem blob 1fd234e100d1 at benchmark base 06bd37614d4e. That blob remains current at the time of this comment. No overlapping Process Performance PR was open; the autonomous portfolio contained three open implementation PRs.

Hypothesis

After one nearby-state change in a wide dataflow graph, current execution constructs futures for every graph task even though clean independent branches only execute empty guarded bodies. A measurement-only prototype scanned initial dirty tasks, propagated activity to all descendants in the cached topological plan, and submitted only the resulting subgraph. It fell back to full-plan submission after three independent dirty roots. No production branch was created.

Reproducible A/B

OpenJDK 17.0.19, Linux x86_64, G1, fixed 768 MiB heap, -XX:ActiveProcessorCount=2. Alternating fresh JVMs used 40 warmups + 160 measurements/fork for SRK and 5 + 10 for SRK-CPA.

The 96-unit process contains eight independent rich-gas trains, each with two feeds, a Mixer, 2–5 heater/cooler pairs, valve, and separator. Sparse runs alternate one train by 50 kg/h; dense runs change all eight; stable runs change none.

Control	Current median	Candidate median	Median change	Paired wins	Caller allocation
Sparse nearby SRK	11.573 ms/run	11.168 ms/run	3.50% faster	2/5	15.34% more
Dense nearby SRK	24.538 ms/run	30.914 ms/run	25.99% slower	1/3	11.43% more
Stable SRK	9.924 ms/run	9.654 ms/run	2.72% faster	2/3	15.98% more
Sparse nearby SRK-CPA	229.668 ms/run	204.838 ms/run	10.81% faster	2/3	1.69% more

Every baseline/candidate fork preserved the exact checksum and reported solved=true. The prototype duplicates expensive needRecalculation() inspection before future bodies perform their normal checks; its sparse SRK target fails the 5%/majority-wins gate, allocation increases in every control, and dense nearby execution regresses materially. The CPA median does not authorize a change against those failures.

Decision: reject the prototype. No code, issue, branch, or PR. A safer future design would need explicit cheap dirty-task metadata maintained by setters/equipment rather than rediscovering dirtiness by rescanning the graph; that is a distinct architecture question, not a micro-optimization.

Documentation impact: none — measurement-only prototype was discarded; user-visible behavior and repository files are unchanged.

[EvenSol]

2026-08-21 profiling — boundary-state buffer reuse rejected

Base: current authoritative master 1505466864a8, GitHub ProcessModel.java blob 5966c16ed47a. The only open user campaign PRs are #3142 (electrolyte/hydrate) and #3143 (thermodynamic documentation); neither owns this process-layer path.

Hypothesis

Each outer ProcessModel iteration creates a new IdentityHashMap and one double[3] state array per boundary stream. A measurement-only prototype used two run-local maps and overwrote their existing state arrays after each comparison. It added no shared/static state and did not alter the public or serialized object graph.

OpenJDK 17.0.19, Linux x86_64, G1, fixed 768 MiB heap, two active processors; alternating fresh JVMs.

workload	baseline median	candidate median	runtime	paired wins	caller allocation
10-area / 900-boundary stable orchestration	0.894 ms	0.864 ms	3.29% faster	4/5	21.95% lower (312,803 → 244,141 B/run)
10-area / 900-boundary nearby-state orchestration	1.055 ms	0.990 ms	6.15% faster	4/5	21.75% lower (315,759 → 247,081 B/run)
representative four-area SRK, stable (100 measured runs/fork)	10.954 ms	11.207 ms	2.31% slower	2/5	0.010% lower
representative four-area SRK, nearby feed	14.044 ms	13.500 ms	3.87% faster	4/5	0.009% lower
representative four-area SRK-CPA	199.578 ms	197.843 ms	0.87% faster	2/3	negligible

The dense orchestration case clears the allocation threshold, but the required representative thermodynamic control does not show an operational throughput/GC benefit and the stable SRK median trends slower. Therefore this does not clear #2939's end-to-end acceptance gate.

Scientific and compatibility controls

• Exact checksum parity in every fork.
• All cases retained two outer iterations, 900/3 boundary diagnostics as applicable, modelConverged=true, and zero reported mass-closure error.
• Nearby-state area-run counts were identical.
• Java 8 source compilation of the local overlays passed.
• Documentation impact: none; the prototype was discarded and changes no API, units, tolerances, serialization, or user-visible behavior.
• No branch, commit, issue, or PR created. Publication/Spotless/documentation gates were not applicable.

Conclusion: retain current allocation behavior. Further boundary-diagnostic work needs evidence from a process with materially more real boundary streams and thermodynamic work, rather than extrapolating the synthetic dense-control gain.

[EvenSol]

2026-08-22 profiling — ProcessModel bypass-list replacement rejected

Base: current authoritative master 59f485417abb, exact GitHub ProcessModel.java blob 5966c16ed47ae5145ce00ca793761196879abdb9. No Process Performance PR is active. The two open user campaign PRs (#3150 and #3151) own safety documentation and reactive thermodynamic clone isolation, not this process-layer path.

Hypothesis

Before every child-area execution, ProcessModel.isFullyBypassed() calls ProcessSystem.getBypassedUnits(), which constructs a diagnostic list and scans every unit before comparing its size with the area size. A measurement-only prototype instead scanned the existing unit list directly and returned at the first active, unlocked unit. The public diagnostic method and serialized state were untouched.

OpenJDK 17.0.19, Linux x86_64, G1, fixed 768 MiB heap, two active processors. Baseline and candidate were compiled with the same Java 8 compiler command against the exact current source blob, then run in alternating fresh JVMs. Each fork used 80 warm-ups and 800 measured model runs.

10-area / 900-boundary workload	baseline median	candidate median	result	paired wins	caller allocation
stable	2.812 ms/run	2.912 ms/run	3.58% slower	2/5	no meaningful change
nearby boundary-flow change	3.090 ms/run	3.080 ms/run	0.34% faster	3/5	no meaningful change

All forks preserved exact checksums, two outer iterations, 900 boundary diagnostics, identical area-run counts, modelConverged=true, and zero reported mass-closure error.

The apparent list/scan overhead is not material after JIT optimization relative to the surrounding ProcessModel diagnostics. The candidate fails #2939's 5% runtime and 15% allocation gates, so broader SRK/CPA testing would not change the publication decision.

• Java 8 source compilation: pass.
• Documentation impact: none; the prototype was discarded and changes no API, behavior, units, defaults, serialization, or recommendations.
• No branch, commit, issue, or PR created.
• Spotless, documentation-search, pre-commit, and pre-push publication gates: not applicable because no repository change was published.

Conclusion: retain the current readable reuse of getBypassedUnits(); do not introduce a second bypass predicate without representative benefit.