accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Coleman (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3329) Consider consolidation of "timing" classes
Date Thu, 21 May 2015 04:42:00 GMT


Ed Coleman commented on ACCUMULO-3329:

A few notes after looking at OpTimer.

1) o.a.a.core.util.StopWatch can only be started once. OpTimer can be started multiple times,
each time increments a counter used in the display messages. StopWatch also takes specific
states related to Accumulo operations.
2) Guava's StopWatch is marked as beta, and like o.a.a.core.util.StopWatch can only be started

There are also many places throughout the code base that call System.currentTimesMillis()
and perform the same time delta operations and could be targets for eventual replacement,
especially if Tracing can be utilized to add additional insight to operation timing.

> Consider consolidation of "timing" classes
> ------------------------------------------
>                 Key: ACCUMULO-3329
>                 URL:
>             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

View raw message