Re: [PATCH v4 06/21] test-date: add a subcommand to measure times in shell scripts

Hi Junio,

On Wed, 23 Jan 2019, Junio C Hamano wrote:

"Johannes Schindelin via GitGitGadget" [off-list ref]
writes:

quoted

From: Johannes Schindelin <redacted>

In the next commit, we want to teach Git's test suite to optionally
output test results in JUnit-style .xml files. These files contain
information about the time spent. So we need a way to measure time.

While we could use `date +%s` for that, this will give us only seconds,
i.e. very coarse-grained timings.

GNU `date` supports `date +%s.%N` (i.e. nanosecond-precision output),
but there is no equivalent in BSD `date` (read: on macOS, we would not
be able to obtain precise timings).

So let's introduce `test-tool date getnanos`, with an optional start
time, that outputs preciser values.

I think the goal to have our own stopwatch so that we do not have to
worry about differences among system-provided ones makes sense.

And so that we do not have to worry about all kinds of unportable shell
commands. That was my main motivation here, TBH.

The only thing that may become an issue is how widely available
getnanotime() is.  As "test-date" itself is built on any platform an
end-user/developer runs our tests, which is wider set of platforms
than what we run Travis and other CIs on, unconditionally relying on
its availability might pose an issue.  I dunno.

Well, getnanotime() itself looks (I checked) at highres_nanos()' output,
which can be 0 on unsuported platforms, and falls back to
gettimeofday_nanos(). The worst that can happen there, as far as I can
tell, is that the platform has a certain granularity (which is true of
highres_nanos(), too), and that granularity can be 1 second. Which is not
very good, but if that's the best the platform can provide, I am prepared
to take it. Which is exactly what this patch does.

Do you have any splendid idea how to improve this approach?

Ciao,
Dscho