[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Would timevar be accepted in gnulib?

From: Bruno Haible
Subject: Re: Would timevar be accepted in gnulib?
Date: Mon, 24 Sep 2018 23:47:18 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-134-generic; KDE/5.18.0; x86_64; ; )

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]