awsomesud347 commented on PR #12130: URL: https://github.com/apache/seatunnel/pull/12130#issuecomment-5565887980
@nzw921rx The re-run is done, at the module's `BenchmarkBase` defaults with `-prof gc`. Fifteen measurements per point rather than three. | Retained jobs | Before | After | Ratio | | --- | --- | --- | --- | | 1,000 | 905,705 ± 50,938 us/op | 24,218 ± 1,004 us/op | 37.4x | | 10,000 | 9,233,153 ± 673,522 us/op | 157,430 ± 16,030 us/op | 58.6x | Relative error is now between 4.1% and 10.2%, against 15% to 43% before. The point estimates barely moved, 36.8x became 37.4x and 58.9x became 58.6x, so the earlier figures were right but poorly evidenced. The allocation data is the part that answers your question about what is being traded away: | Retained jobs | Before | After | Reduction | | --- | --- | --- | --- | | 1,000 | 1,172 MB/op | 29.9 MB/op | 39.1x | | 10,000 | 12,761 MB/op | 211 MB/op | 60.3x | At ten thousand retained jobs, GC time over the trial fell from 2,644 ms to 468 ms and collections from 144 to 80. So at that size the old path allocated roughly 12.7 GB in order to return ten rows. That is the answer to what was sacrificed, which is nothing: the allocation reduction of 60.3x tracks the timing reduction of 58.6x almost exactly, which is what you would expect if the change simply stops building rows that were discarded immediately afterwards. It is not a trade of one cost against another. To be clear on scope, this closes the GC part of what you asked about. I still have not run a flame graph or JFR, so that part of the gap remains open. Say the word if you want either and I will do them. Two caveats on the method, both carried over from my previous comment. The first is that the baseline calls this branch's refactored unpaged method rather than dev's, so it includes one extra list allocation that dev does not have. At roughly 40 KB against 12,761 MB that is immaterial. The second matters more: `preloadStoragePressure` stores the same `JobState` instance under every key, so all the metrics lookups hit a single key in one partition, whereas real traffic would spread across distinct keys and partitions. That second one flatters the old path far more than the new one, since it performs twenty thousand of those lookups against twenty. If lookups became more expensive the old figure would rise sharply while the new one barely moved, because roughly 94% of its remaining cost is the scan. So the absolute times and allocations here are optimistic for both paths, but the ratio is if anything conservative rather than inflated. Thanks also for catching `/running-jobs/summary`. That is now named in the incompatibility entry in both languages. -- 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]
