Hi Junio, On Wed, 23 Jan 2019, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > > > From: Johannes Schindelin <johannes.schindelin@xxxxxx> > > > > 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
