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

[Eddy Petrișor]

2014/1/14 Tim Murphy <address@hidden>
>
> To some, using a spreadsheet might not seem like the most worthwhile
> way to visualise timing information.


That's why I thought it can be useful to provide the information in
various formats.

I found useful the graphs provided via a graph from data in
spreadsheet, you need the info to scale to some higher level. I think
the best compromise are the different formats provided by my latest
patch version.

>
> If it was me, I'd be far more concerned about whether I could write a
> script that could easily cope with all this information.  Builds with
> hundreds of thousands of targets were common for me at one point and
> nowadays I do android stuff - how much is that?  I think it's
> somewhere around 36,000.
>
> This scale makes spreadsheets relatively unimportant as an analysis
> tool and makes it necessary to pass information through a script to
> first extract or summarise the information to a level where humans can
> deal with it.
>
> Hence:
>  a)  an absolute start time and
>  b)  a duration


That is provided by the 'simple' format.

>
> ...are easy to process in scripts to reconstruct whatever form one
> needs - a spreadsheet for you and a different kind of special graph
> for me. Both examples of a profiling feature for make that I'm aware
> of already use this format to good effect.
>
> It's also worth trying to produce these figures as each job finishes
> and then throw them away because then the build doesn't have to finish
> before one is able to process the data. You might use it, for example
> to provide progress information.  e.g. if you keep information from a
> previous build and combine it with profiling information coming out of
> the new build you can guess how long is left.


I think this fits with Paul's suggestion to keep the info in the
commands structure. I am unsure if this would do the job, but I see
the benefit in providing the info ASAP, so if I can avoid any
unnecessary delays, I will.

I have tried the sort of scenario you think of in one of the build
systems I maintain and a simple grep through stderr for '^PROFILING'
can isolate the profiling info during the build.


> I forgot to say that start times don't need to be absolute times -
> only relative to the start of the top level gmake if possible.   That
> creates a problem for submakes I suppose.
>
> I would guess that one could put the absolute build start time in an
> environment variable like MAKE_START_TIME and then use that in every
> submake to get the relative start time.
> I haven't looked at the patch - perhaps it's doing this?

I tried this in local branch, but wasn't successful (code is not
published for that attempt to avoid confusion around which code to
review).

> In any case, fixed/floating point seconds since 1970 is the nicest
> format to process from scripts in my experience.

That is what is printed now, where applicable.

-- 
Eddy Petrișor