[jira] [Closed] (NUTCH-3013) Employ commons-lang3's StopWatch to simplify timing logic

["Lewis John McGibbney (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/NUTCH-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lewis John McGibbney closed NUTCH-3013.
---------------------------------------

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