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

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

Github user garydgregory commented on the issue:

    https://github.com/apache/commons-lang/pull/311
  
    I hope we do not advocate running code like the fragment you just quoted. 
This is the same kind of issue we finally resolved in Apache Log4 2 where you 
no longer need to write code like:
    
    ```
    if (logger.isDebugEnabled()) {
       logger.debug("This is " + foo + " and " +bar);
    }
    ```
    
    Instead you say:
    
    `logger.debug("This is {} and {}", foo, bar);`
    
    You can also delegate evaluation of expensive calls only if the logger is 
enabled:
    
    `logger.debug("This is {} and {}", () -> foo(), () -> bar());`
    
    The logger is configured from a file or another code snippet.
    
    IMO, we are already dangerously close to out of bounds of [lang] with the 
current code, so I am mentioning this for exploration ATM. That said, I think 
it would be good to see in text at least what a fully featured gadget looks 
like before we include the current version in [lang]. Once in, it will likely 
evolve, and then it might end up being moved to another component if it is no 
longer 'lang-y'...



> 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)

Reply via email to