Add Timer to OP2Utility to support basic instrumentation

[Brett208]

I've used the same Timer in OP2MapImager and MissionScanner for rudimentary instrumentation. Maybe it would be worth pulling into OP2Utility to prevent from copy/pasting it into different projects in the future.

I wouldn't be looking to make it perfect, just getting it centralized in case work is continued on it in the future, it would be available to all projects.

If this seems a distraction to the mission of OP2Utility, I would be ok dropping this issue, just wanted to bring it up because the workflow would have been nicer.

#include "Timer.h"

using namespace std;
using namespace std::chrono;

void Timer::StartTimer()
{
    startTime = high_resolution_clock::now();
}

double Timer::GetElapsedTime()
{
    high_resolution_clock::time_point currentTime = high_resolution_clock::now();
    duration<double> time_span = duration_cast<duration<double>>(currentTime - startTime);

    return time_span.count();
}

[DanRStevens]

Mixed feelings on this one. This is nice to have, though also not really related to the project. Additionally, to be more fully usable, it should perhaps also contain the table formatting code for the time result.

Related, Linux has a time utility. You can wrap any command with time and it will print a summary table at the end showing elapsed time. It includes wall clock time (what is measures by your code), as well as breaking it down into time spent executing user mode code, and time spent in kernel mode (calls to the OS). The difference between the wall clock time and the sum of the two component times also provides some indication of how long the code spends idle waiting, such as waiting for disk buffers to be filled, which may involve disk seek time, or queued read time.

Actually, it seems Windows may already have a built-in equivalent of time: https://superuser.com/questions/228056/windows-equivalent-to-unix-time-command

[Brett208]

The benefit of Chrono is that it is contained within the STD library. Would you prefer to try and use compiler specific solutions and preprocessor directives? I hadn't thought of that.

I was more looking to get something started in the library than a perfect solution. Is it a requirement that it be more polished before pulling in?

[DanRStevens]

To clarify, the alternates I proposed are console tools, not library methods. For crude timing checks at the level of executing a console program, they are highly appropriate.

[DanRStevens]

I'm looking back at this one and kind of leaning towards closing as out of scope for the library.