[
https://issues.apache.org/jira/browse/LANG-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373848#comment-16373848
]
Gilles commented on LANG-1373:
------------------------------
{quote}I don't think throwing an exception or ? to get the Stack info just to
keep from naming a timing is in line with the purpose of the feature, for
performance reasons.
{quote}
No need to throw the exception, just instantiate it and get the trace. True, it
has a cost.
But the benefit in ease of use is perhaps worth it; moreover, the cost will
probably decrease with Java 9 ({{StackWalker}}).
What are the performance requirements?
{quote}The user doesn't have to figure out a naming scheme. They just have to
give the timing a name.
{quote}
That's what I meant by "naming scheme"; the use-cases shown in the unit tests
seem to confirm that such a scheme, although required by the current API, is
actually not necessary.
{code:java}
void functionOneOne(StackWatch<String> watch) {
watch.startTiming("OneOne", "OneFunc");
// ...
}
void functionOneTwo(StackWatch<String> watch) {
watch.startTiming("OneTwo", "OneFunc");
// ...
}
{code}
In the above excerpt, the "name" looks redundant:
* function name = "functionOneOne" -> timing name = "OneOne"
* function name = "functionOneTwo" -> timing name = "OneTwo"
Auto-generating the "name" simplifies the API and makes the usage more robust,
in a sense, since the user cannot make the mistake of naming the timings in an
inconsistent way.
From the following sequence of statements:
{code:java}
public void testStackWatchCallStackNames() {
StackWatch<String> watch = new StackWatch<>("testStackWatch");
watch.start();
watch.startTiming();
functionOne(watch);
functionTwo(watch);
functionThree(watch);
watch.stopTiming();
watch.stop();
}
{code}
(no "name" argument to the {{startTiming}} methods), the user would get (from
visiting all the nodes):
{noformat}
testStackWatch
testStackWatch/testStackWatchCallStackNames
testStackWatch/testStackWatchCallStackNames/functionOne
testStackWatch/testStackWatchCallStackNames/functionOne/functionOneOne
testStackWatch/testStackWatchCallStackNames/functionOne/functionOneOne/functionOneTwo
testStackWatch/testStackWatchCallStackNames/functionTwo
testStackWatch/testStackWatchCallStackNames/functionTwo/functionTwoOne
testStackWatch/testStackWatchCallStackNames/functionTwo/functionTwoOne/functionTwoTwo
testStackWatch/testStackWatchCallStackNames/functionThree{noformat}
> 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
>
> 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)
