Hi Akim, > > Two other points worth documenting: > > * When the program invokes subprocesses, which of the times (usr, sys, > > wall) include the times of the subprocess, and with which multiplicity? > > I don’t know what you name multiplicity :/
Multiplicity is probably a wrong term. What I mean is: Suppose a program invokes 10 subprocesses, and the xyz-time of each is t1, t2, ..., t10, whereas the xyz-time of the process without the subprocesses is t0. The reported xyz-time could be - just t0 - or t0 + t1 + ... + t10 - or t0 + max (t1,...,t10) - or possibly max (t0, t1,...t10) How the reported time is composed, is something the user needs to know in order to interpret the figures. > > * When the program creates additional threads and these threads terminate > > within the particular phase, which of the times (usr, sys, wall) > > include the times of the threads? > > I don’t have a use case here, so I dunno what users would expect. I don't know/think users can expect something here. But the documentation should state how the time spent in threads (partially running in parallel) contribute to the reported time. The point is that I would expect that the composition formula is different for, say, usr than wall. Then an output "7.5 usr 0.0 sys 2.0 wall" may be surprising output. The documentation should resolve this surprise. > Not too mention that I have no experience > of the portability of these guys. We can help with portability questions, on this list. > I won’t submit timevar immediately, I’ll have to do my homework fist. You can submit it already without support for high-res timers. That can come afterwards, even if it will necessitate API changes. It's not a blocker issue. Bruno
