[
https://issues.apache.org/jira/browse/BEAM-12142?focusedWorklogId=580150&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-580150
]
ASF GitHub Bot logged work on BEAM-12142:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 09/Apr/21 17:05
Start Date: 09/Apr/21 17:05
Worklog Time Spent: 10m
Work Description: kennknowles commented on a change in pull request
#14498:
URL: https://github.com/apache/beam/pull/14498#discussion_r610780330
##########
File path:
sdks/java/core/src/main/java/org/apache/beam/sdk/metrics/MetricsEnvironment.java
##########
@@ -52,8 +53,8 @@
private static final AtomicBoolean METRICS_SUPPORTED = new
AtomicBoolean(false);
private static final AtomicBoolean REPORTED_MISSING_CONTAINER = new
AtomicBoolean(false);
- private static final ThreadLocal<@Nullable MetricsContainer>
CONTAINER_FOR_THREAD =
- new ThreadLocal<>();
+ private static final ThreadLocal<@Nullable MetricsContainerHolder>
CONTAINER_FOR_THREAD =
Review comment:
Is it always no longer `@Nullable`? Could possible localize
`@SuppressWarnings` to this initialization line? (just an idea)
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 580150)
Time Spent: 50m (was: 40m)
> Reduce overhead of MetricsEnvironment
> -------------------------------------
>
> Key: BEAM-12142
> URL: https://issues.apache.org/jira/browse/BEAM-12142
> Project: Beam
> Issue Type: Bug
> Components: java-fn-execution
> Reporter: Sam Whittle
> Assignee: Sam Whittle
> Priority: P2
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently the MetricsContainer objects are stored in ThreadLocal state. This
> means that scoping a new container involves a get and a set of thread-local
> state. By instead putting a wrapper object in the thread-local state we can
> use a single-lookup in thread local state to get/set and then reset.
> This is showing up as a possible 7% cpu improvement in a nexmark query
> benchmark
> Additionally I think that removing from the threadlocal state is causing
> overhead in get calls by causing the linear probing within the implementation
> of ThreadLocal state to become more expensive.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
