[
https://issues.apache.org/jira/browse/ACCUMULO-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14554608#comment-14554608
]
Josh Elser commented on ACCUMULO-3329:
--------------------------------------
bq Guava's StopWatch is marked as beta
Oh wow, I didnt' realize it's still in beta.
bq. OpTimer can be started multiple times
A cursory glance over the code, I don't see any cases where we actually do
this. I think it may just be a non-handled corner case in the class.
bq. each time increments a counter used in the display messages
Same here, I'm not seeing an instance where this is used (but I haven't looked
exhaustively)
Ultimately, I think there is leeway in this consolidation to make timing some
codepath done in one and only one way. I don't think we need to focus on
maintaining what is possible by each of these classes, but really think about
what timings/info are useful and make a single entry point to handle all of it.
> Consider consolidation of "timing" classes
> ------------------------------------------
>
> Key: ACCUMULO-3329
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3329
> Project: Accumulo
> Issue Type: Improvement
> Components: client, master, tserver
> Reporter: Josh Elser
> Labels: newbie
> Fix For: 1.8.0
>
>
> We have a number of "timing" classes in or used by the codebase
> * org.apache.accumulo.core.util.StopWatch
> * org.apache.accumulo.core.util.OpTimer
> * Traces
> * Guava's Stopwatch
> I'm assuming that consolidation of all of the timings into Traces would be
> the best (assuming that if we care about the timing of a given operation
> implies that we would also care about the timing of the "bigger picture").
> If we can remove some of our timer classes, that would be great. Not
> suggesting that we forcibly prevent the use of Stopwatches/TImers in the
> codebase entirely -- just where it makes sense.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
