2014/1/14 Tim Murphy <tnmur...@gmail.com> > > 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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make