davsclaus commented on PR #28819:
URL: https://github.com/apache/camel/pull/28819#issuecomment-6735330164

   Thanks @ammachado for the work here, and for the honest write-up of the 
tradeoff in the description. After going through it again, we have decided not 
to merge it. The reason is the complexity versus the gain, not the quality of 
the PR: the code is careful and every case has a test that targets it. The 
approval above was on correctness alone.
   
   Why we are declining:
   
   - **The gain only shows on routes that do nothing.** Going by your numbers 
(about 545k vs 690k ops/s with 20 clock reads per exchange), one `nanoTime` 
costs about 19 ns on Linux. On a route with a 1 ms call that is about 0.02%, as 
you wrote.
   - **It does not touch the multi-threaded cap.** At 8 threads there was no 
clear change. The September analysis in CAMEL-25132 found that cap is the 
per-processor counter updates, not the clock. The quick wins (a) went in with 
CAMEL-26393, and the striped-counter design (b) is where the next big win is.
   - **A mistake would be silent.** Seven cases now have to clear the saved 
time: route start, a failed node, nodes without statistics, nested nodes, loop 
iterations, stream caching and delayer/debugger/tracer work. Every future 
feature that waits or does work between nodes has to remember to clear it too: 
a new EIP, async processors, chaos delays, the sanitizer. If one forgets, 
nothing fails; JMX just reports the time on the wrong node, which is hard to 
notice and hard to track down.
   - **It costs everyone.** It adds a field on every exchange, also without 
JMX, and two methods on `ExchangeExtension` in camel-api.
   - **There is already a setting for this.** Users who care about this 
overhead can use `ManagementStatisticsLevel` `RoutesOnly` or `Off`.
   
   If the striped counters land and the clock reads then show up as the main 
cost, the idea can come back with JMH numbers. Your work here, and your 
analysis of where the time must not be reused, would be the starting point. 
Thanks again!
   
   _Claude Code on behalf of davsclaus. This comment was generated by an AI 
agent and may contain inaccuracies._
   


-- 
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]

Reply via email to