SEZ9 commented on issue #12058: URL: https://github.com/apache/seatunnel/issues/12058#issuecomment-5642813148
@Rangsh thanks — I confirm your reading of the unchanged `origin/dev` baseline. The `flame-wall-reverse.html` / `flame-wall-forward.html` stacks under `jmhStub` → `updateCheckpointOverview` (≈60% of timed-path wall samples in `updateOverview` → `MapProxyImpl.compute` → `InvocationFuture.get` → `LockSupport.park` / `Unsafe.park`), together with `hsync` at only 0.82% of CPU samples in `flame-cpu-forward.html` and the `205.64` / `115.29` Run B samples not lining up with GC pauses in the A/A gist logs, support your one-sentence cause: the variance for `checkpointOverviewIncrementalUpdate$` is wall-clock blocking on the Hazelcast write-through wait (`InvocationFuture.get` / `RequestFuture` → WAL `hsync` on `file:///`), not GC and not CPU-heavy work inside `hsync`. Root-cause step accepted. Agreed on the loop as well. Before the first single-variable change, please post here: 1. The exact candidate change (one variable only) and which frame in the wall stack above is expected to shrink. 2. The semantic invariants it preserves — in particular that the write-through durability contract is unchanged (no MapStore mode change, no disabling persistence, nothing that only hides the wait). 3. Confirmation you will re-run `tools/benchmarks/profile_benchmarks.sh` (`wall` / `cpu` / `gc`) on the same Corretto 11.0.26 / Apple M1 setup with the same initial data and workload, and attach the new flame HTML alongside the baseline ones so the hotspot delta is visible — Score/Error/CV movement alone won't be treated as evidence. Once that's posted and looks right, go ahead with the A/B run. <!-- streview-comment:976 --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
