Hi Junio,

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

> "Johannes Schindelin via GitGitGadget" <gitgitgad...@gmail.com>
> writes:
> 
> > From: Johannes Schindelin <johannes.schinde...@gmx.de>
> >
> > 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

Reply via email to