[
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376111#comment-16376111
]
Gilles commented on LANG-1373:
------------------------------
{quote}I have fixed the visit issue
{quote}
The path is reversed:
{noformat}
Visit level 0 timing: OuterFunction path: [OuterFunction]
Visit level 1 timing: One path: [One, OuterFunction]
Visit level 2 timing: OneOne path: [OneOne, One, OuterFunction]
Visit level 3 timing: OneTwo path: [OneTwo, OneOne, One, OuterFunction]
Visit level 1 timing: Two path: [Two, OuterFunction]
Visit level 2 timing: TwoOne path: [TwoOne, Two, OuterFunction]
Visit level 3 timing: TwoTwo path: [TwoTwo, TwoOne, Two, OuterFunction]
{noformat}
It might be construed as a feature. ;) But it does not correspond to the output
advertised in the documentation.
{quote}javadoc using the hybrid <code> and \{@code} approach.
{quote}
What about trying the simpler approach of using a single \{@code <here comes
the whole example>} ?
Sorry for the seeming nit-pick but it is really nicer if an example can be run
without having to clean it first (except for the leading "*"). By the way, I
strongly suggest to add this example in the unit test suite (checking that the
paths are as intended, instead of printing).
Does a user of the feature need {{getChildren()}}? If not, better remove it
from the API.
{quote}Gilles, feel free to take over and prepare the merge if you'd like, or
just ping me if/when you are happy with the code and LGTM.
{quote}
Bruno,
Will you please do this, after the above remarks have been taken into account?
Thanks. And sorry for interfering with your handling of this feature. But you
asked for it! ;)
> 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)
