Re: [bug #40639] GNU Make with profiling information

[Eddy Petrișor]

Pe 11.01.2014 20:58, "Paul Smith" <address@hidden> a scris:
>
> Sorry, I've been mostly away from my systems recently.
>
>
> On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote:
>
> > Thanks for clarifying this. Could you please confirm if the general
> > direction of the the is OK in the latest patch I sent?
>
> I will take a look.
>
> > What it is in scope and what I would need help with is adding relative
> > time stamp support in the profiling info instead of absolute time
> > stamps. When analyzing the 'simple' output I realised the graphs
> > looked awful because there was such such a scale difference between
> > the time stamp and duration.
> > The absolute time stamp also doesn't fit well worth the scope of the
> > 'simple' output.
>
> Does it have to be relative to the start of the entire build (user's
> invocation of make)?

Not necessarily. It can be relative to the first finished target or to some arbitrary start time. The idea is to easily analyse the extracted data without the need for extra effort.

>
> I understand the interest in the amount of time a given job takes to
> run, but I guess I don't understand the need for a "start time offset"
> at all.  Isn't it sufficient to record the start time of a job, then
> when it's complete show the elapsed time for that job?  Or recipe?  Or
> both?

The resulted information when using absolute time stamps is almost meaningless until they are further processed in an external tool because is hard to identify with a glance which job finished last, which first and so on.

If a relative time stamp is provided one can waste less time on the analysis when some target is clearly the wasteful one. Also the relative time stamps generate very readable graphs directly after insertion in a tool such as Oocalc, Gnumeric or Excel. With absolute time stamps the very first thing I found myself doing was to generate relative time stamps.

>
> > I tried to pass down a reference time stamp through an environment
> > variable, but I am missing something from the processing since
> > submakes don't see the variable I defined.
>
> I'll take a look.
>

Sorry for not sending that. Since I had no feedback I wanted to avoid the confusion regarding which code to review.