LMPEvi commented on issue #6870: URL: https://github.com/apache/incubator-kie/issues/6870#issuecomment-5580073984
Thank you! Unfortunately, I'm not able to share much due to confidentiality. I did run benchmarks of a representative workload; an input material with 100k rows with both our current production version that uses v8.44.2.Final, as well as a version that uses the patched v10 version. V8.44.2.Final CPU benchmark: <img width="2442" height="1602" alt="Image" src="https://github.com/user-attachments/assets/23101852-fbe2-4067-8788-aeaf867cbd8b"; /> V8.44.2.Final memory benchmark: <img width="2218" height="1458" alt="Image" src="https://github.com/user-attachments/assets/24286616-fb62-4469-a6b6-1ee545a42532"; /> V10 CPU benchmark: <img width="2740" height="1502" alt="Image" src="https://github.com/user-attachments/assets/9da5c1b9-e4fb-4db1-bd2e-fa081e3340d9"; /> V10 memory benchmark: <img width="2733" height="1680" alt="Image" src="https://github.com/user-attachments/assets/66daa16a-b206-4afa-8ada-300123259313"; /> I did also ask Copilot to analyse the benchmarking snapshots and here is what it found. I haven't verified any of this in detail, so take it with a grain of salt. Unfortunately I can't share the full benchmarking snapshots due to confidentiality, but do let me know if there is something specific I could share that would aide you. ``` Performance Regression Analysis: Drools v8.44.2 → v10.2.0 Overall Impact Baseline (v8.44.2): 157 seconds, 91,666 CPU samples, ~71k non-idle samples v10 (v10.2.0): 328 seconds, 181,176 CPU samples, ~160k non-idle samples Regression factor: ~2.1x slower Root Causes of the v10 Regression 1. FEELImpl.newEvaluationContext — massively heavier context setup This is the single biggest regression factor. In v10 it appears in 11.9% of all samples (inclusive), versus 8.1% in the baseline. In absolute terms: 21,549 vs 7,431 samples (~2.9x increase). Inside newEvaluationContext, v10 spends dramatically more time in: LinkedHashMap.forEach: 5,132 samples (v10) vs 849 (baseline) — 6x increase. v10 iterates over more entries when copying/initialising the evaluation context. AbstractCollection.addAll: 1,146 vs 350 — 3.3x increase. EvaluationContextImpl.<init>: 304 vs 36 — 8.4x increase. This indicates that Drools v10 creates a larger or more deeply nested EvaluationContextImpl per expression evaluation, copying significantly more data each time. 2. Increased HashMap overhead — more copying and resizing The dominant self-time method in v10 is HashMap.putVal with 25,168 samples vs 5,352 in baseline (4.7x increase). Related: HashMap.putMapEntries: 6,950 vs 4,521 (1.5x) HashMap.resize: 4,758 vs 2,006 (2.4x) HashMap.getNode: 5,204 vs 1,016 (5.1x) LinkedHashMap.newNode: 2,122 vs 1,087 (2x) This means v10 is creating and populating substantially more HashMap instances, consistent with the heavier context setup. 3. Logging overhead (new in v10) TurboFilterList.getTurboFilterChainDecision: 1,318 samples in v10 self-time (not present in baseline top-40). Formatter.<init> (used by String.format in log messages): 1,005 samples in v10 self-time. Total logging-related stack samples: ~4,336 in v10. This indicates v10's FEEL engine added trace/debug logging calls that, even when the log level filters them out, still incur TurboFilter evaluation and String.format argument construction overhead on every call. 4. Higher memory pressure Baseline post-GC heap: ~1.0–1.2 GB v10 post-GC heap: ~1.4–1.6 GB Allocation samples: 39,318 (v10) vs 18,278 (baseline) — 2.15x more allocations LinkedHashMap$Entry allocations: 4,208 (v10) vs 1,904 (baseline) — 2.2x ``` -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
