commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LANG-1373) Stopwatch based capability for nested, named, timings in a call stack
Date Mon, 26 Feb 2018 18:28:01 GMT

    [ https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377320#comment-16377320
] 

ASF GitHub Bot commented on LANG-1373:
--------------------------------------

Github user ottobackwards commented on the issue:

    https://github.com/apache/commons-lang/pull/311
  
    Sorry @garydgregory I understood you to mean it would be optional.
    
    So, the context of the creation of this idea is I did it for an environment where we have
optional available 'capabilities', and it is common to check and use if present or fail if
required but not present.
    
    There is a difference between the logging example and this.  I am familiar with logging
quick fail ( I implemented my own c++ streams based quick failing logger back in the day even
), but the logger is always there, you are checking for configuration or optionally enabled
functionality ( debug logging ), where as I wrote this for an environment where we may not
have a watch at all.
    
    I am not saying having a 'singleton' watch, with a 'do nothing' set of default interface
implementations isn't something to think about.
    
    But things start from where you have a need usually.
    



> Stopwatch based capability for nested, named, timings in a call stack
> ---------------------------------------------------------------------
>
>                 Key: LANG-1373
>                 URL: https://issues.apache.org/jira/browse/LANG-1373
>             Project: Commons Lang
>          Issue Type: New Feature
>          Components: lang.time.*
>            Reporter: Otto Fowler
>            Assignee: Otto Fowler
>            Priority: Major
>              Labels: commons-lang,
>         Attachments: LANG-1373.patch
>
>
> While working on adding some timing functionality to a Metron feature, I came across
the
> Stopwatch class, but found that it didn’t suite my needs.
> What I wanted to do was to create a timing from a top level function in our Stellar dsl,
and have have a group of related timings, such that the end result was the overall time of
the call, and nested timings of other calls executed during the dsl execution of that function.
These timings would all be named, and have a path for identification and include timing the
language compiler/execution as well as the function execution itself. It would be helpful
if they were tagged in some way as well, such that the consumer could filter during visitation.
> So I have written StackWatch to provide this functionality, and submitted it in a Metron
PR.
> From the PR description:
> StackWatch
> A set of utility classes under the new package stellar.common.timing have been added.
These provide the StackWatch functionality.
> StackWatch provides an abstraction over the Apache Commons StopWatch class that allows
callers to create multiple named and possibly nested timing operations.
> <…>
> This class may be more generally useful to this and other projects, but I am not sure
where it would live since we wouldn’t want it in common.
> StackWatch uses a combination of Deque and a custom Tree implementation to create, start
and end timing operations.
> A Visitor pattern is also implemented to allow for retrieving the results after the completion
of the operation.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message