[
https://issues.apache.org/jira/browse/NUTCH-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on NUTCH-3013 started by Lewis John McGibbney.
---------------------------------------------------
> Employ commons-lang3's StopWatch to simplify timing logic
> ---------------------------------------------------------
>
> Key: NUTCH-3013
> URL: https://issues.apache.org/jira/browse/NUTCH-3013
> Project: Nutch
> Issue Type: Improvement
> Components: logging, runtime, util
> Affects Versions: 1.19
> Reporter: Lewis John McGibbney
> Assignee: Lewis John McGibbney
> Priority: Minor
> Labels: timing
> Fix For: 1.20
>
>
> I ended up running some experiments integrating Nutch and [Celeborn
> (Incubating)|https://celeborn.apache.org/] and it got me thinking about
> runtime timings. After some investigation I came across [common-lang3's
> StopWatch
> Class|https://commons.apache.org/proper/commons-lang/javadocs/api-release/index.html?org/apache/commons/lang3/time/StopWatch.html]
> which provides a convenient API for timings.
> Seeing as we already declare the commons-lang3 dependency, I think StopWatch
> could help us clean up some timing logic in Nutch. Specifically, it would
> reduce redundancy in terms of duplicated code and logic. It would also open
> the door to introduce timing _*splits*_ if anyone is so inclined to dig
> deeper into runtime timings.
> A cursory search for *_"long start = System.currentTimeMillis();"_* returns
> hits for 32 files so it's fair to say that timing already affects lots of
> aspects of the Nutch execution workflow.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
