[
https://issues.apache.org/jira/browse/CAMEL-26475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140984#comment-18140984
]
Claus Ibsen commented on CAMEL-26475:
-------------------------------------
Declined, see the PR comment:
https://github.com/apache/camel/pull/28819#issuecomment-6735330164
Thanks ammachado for the work and the honest write-up of the tradeoff. The
reason is the complexity versus the gain, not the quality of the PR:
* The gain only shows on routes that do nothing. One nanoTime costs about 19 ns
on Linux, so with a 1 ms call the saving is about 0.02%.
* At 8 threads there was no clear change. The multi-threaded cap is the
per-processor counter updates (CAMEL-25132 item 1). The quick wins (a) are in
CAMEL-26393, and the striped counters (b) are where the next win is.
* Seven cases have to clear the saved time, and every future feature that waits
or does work between nodes would have to as well. If one forgets, nothing
fails: JMX just reports the time on the wrong node.
* It adds a field on every exchange, also without JMX, and two methods on
ExchangeExtension in camel-api.
* 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,
this can be reopened with JMH numbers.
_Claude Code on behalf of davsclaus_
> camel-management - one nanoTime per node for the processor statistics
> ---------------------------------------------------------------------
>
> Key: CAMEL-26475
> URL: https://issues.apache.org/jira/browse/CAMEL-26475
> Project: Camel
> Issue Type: Sub-task
> Reporter: Adriano Machado
> Assignee: Adriano Machado
> Priority: Major
> Fix For: 4.24.0
>
>
> Item \(c\) of the JMX statistics section of CAMEL\-25132. With the default
> statistics level, each node reads {{nanoTime}} twice. Measured on JDK 21
> Linux, single threaded, on a 10 node route that does nothing: 545k exchanges
> per second, 690k without {{nanoTime}}, and 695k without {{nanoTime}} and
> without the {{StopWatch}} allocation, so the cost is the clock reads and not
> the allocation.
> A prototype that reuses the end time of the previous node as the start of the
> next node reached 603k \(\+10.6%\), about 175 ns per exchange on that route.
> The saving per exchange is fixed, so it is small on a route that does real
> work. It costs 8 bytes on every exchange, also without JMX, and an addition
> to {{ExchangeExtension}}. This will be a draft pull request so that the
> tradeoff can be decided in review.
> A reused time must never be stale: a route reads a fresh time, and a failure
> or a node without statistics clears it.
> _Claude Code on behalf of Adriano Machado \(@ammachado\)_
> _This was generated by an AI agent and may contain inaccuracies. Please
> verify before relying on it._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
