[
https://issues.apache.org/jira/browse/IGNITE-13411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193451#comment-17193451
]
Alexander Lapin commented on IGNITE-13411:
------------------------------------------
[~alex_pl]
Patch looks good to me, especially items 1({{GridNioTracerFilter}}) and 2(null
instead NOOP TraceSurroundings). To be honest, in general, I don't like an idea
of extra boilerplate code with explicit span creation, however, cause it works
faster than permanent MTC.span().addLog() ot similar I'm also fine with that.
LGTM.
> Optimize tracing when NoopTracingSpi is used
> --------------------------------------------
>
> Key: IGNITE-13411
> URL: https://issues.apache.org/jira/browse/IGNITE-13411
> Project: Ignite
> Issue Type: Improvement
> Affects Versions: 2.9
> Reporter: Aleksey Plekhanov
> Assignee: Aleksey Plekhanov
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Current tracing implementation has some redundant actions for no-op tracing
> SPI which have a negative impact on performance:
> # {{GridNioTracerFilter}} added to communication SPI filters chain even if
> tracing is disabled.
> # {{MTC.support}}/{{MTC.supportContinual}} methods in case of no-op span or
> null span return {{TracingSurrounding}} which equivalently does nothing
> ({{span.set(oldSpan)}} is redundant, since {{span.set(startSpan)}} was
> skipped for no-op or null span, and {{endRequired}} is always {{false}}. So,
> instead of creating new {{TracingSurrounding}} we can return {{null}}
> (correctly processed by try-with resource block) with the same effect and get
> rid of some code on the hot path.
> # Sometimes we already have {{Span}} on hands and call to {{MTC.span()}} is
> redundant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
