[
https://issues.apache.org/jira/browse/BEAM-11727?focusedWorklogId=548927&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-548927
]
ASF GitHub Bot logged work on BEAM-11727:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 05/Feb/21 23:53
Start Date: 05/Feb/21 23:53
Worklog Time Spent: 10m
Work Description: kennknowles commented on a change in pull request
#13861:
URL: https://github.com/apache/beam/pull/13861#discussion_r571312280
##########
File path:
runners/core-java/src/main/java/org/apache/beam/runners/core/metrics/ExecutionStateSampler.java
##########
@@ -36,8 +36,7 @@
/** Monitors the execution of one or more execution threads. */
public class ExecutionStateSampler {
- private final ConcurrentSkipListSet<ExecutionStateTracker> activeTrackers =
- new ConcurrentSkipListSet<>();
+ private final HashSet<ExecutionStateTracker> activeTrackers = new
HashSet<>();
Review comment:
`@GuardedBy(this)`? Or a comment to that effect. Minor benefit of the
annotation over a comment is that there are analyses (including
checkerframework that we already use) that can check them statically or
dynamically.
----------------------------------------------------------------
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: 548927)
Time Spent: 50m (was: 40m)
> Optimize ExecutionStateSampler
> ------------------------------
>
> Key: BEAM-11727
> URL: https://issues.apache.org/jira/browse/BEAM-11727
> Project: Beam
> Issue Type: Bug
> Components: runner-core
> Reporter: Sam Whittle
> Assignee: Sam Whittle
> Priority: P2
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Showed up as 1.5% of CPU on Nexmark 11 streaming benchmark run.
> It appears to be using a ConcurrentSkipListSet and most of the cpu is
> relatedd to inserts/removes in that, involving the system hash of the entries
> as that is used for ordering.
> The consistent ordering is unnecessary. Additionally for other reasons,
> removal and iteration is already synchronized and so performance will likely
> be better just using a synchronized HashMap and synchronizing in the add case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
