[ https://issues.apache.org/jira/browse/NUTCH-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lewis John McGibbney resolved NUTCH-3013. ----------------------------------------- Resolution: Fixed Thanks for the review [~snagel] > 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)