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

[Paul Smith]

On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote:
> Could you please confirm if the general direction of the the is OK in
> the latest patch I sent?

Conceptually it seems OK.  I'm still not jazzed about having any more
than one output format, and I'd prefer that format to be in a
more-or-less readable form, more like the "long" form than the others.

I think the output should go in the standard make output format, so
something like:

  make[<LVL>]: <target>: <details...>

Or, alternatively:

  <target>[<LVL>]: <details>

Also I think it's enough to show the start offset and the elapsed time.
End offset is not necessary IMO.

I'm unsure about the PID.  This is the pid of the make process so I'm
not sure what the goal is.  Is it to be able to collect all the times
together maybe?

Is it necessary to dump all the output times at the end?  Doing so
requires that we increase the size of the file structure to hold the
information, and this is already large AND the most common structure in
memory; there's one for every single target which for non-recursive
builds can get really big.  I'm trying to keep memory usage under
control.

If instead of that we print the information after each target is
complete we can shift the storage of this information out of the file
structure and into the commands structure or similar.  To me it seems
more useful to keep the elapsed time info right next to the command
output rather than dumping it all at the end.

Some other comments:
     1. In general remember that GNU make code must conform to ANSI
        C89 / ISO C90.  We shouldn't be using newer features of the
        language or runtime library unless we need to, and most of those
        require some kind of autoconf test.
     2. Let's avoid float and double (and struct timeval).  There's no
        reason why we can't fit enough precision in a uint32 to count
        elapsed time in milliseconds for a build: that gives 50 days or
        so.  GNU make still supports running on systems where there is
        no floating point support (see the NO_FLOAT #define).  Although
        I haven't tested it in a while.
     3. The use of "$" tokens in printf() statements is likely
        problematic from a portability standpoint.  It seems like this
        should be relatively easy to avoid.
     4. If the printed string contains text then it needs to be marked
        for translation (with the "_(...)" macro).
     5. We don't want to be using fprintf() here.  All output needs to
        go through the output.c module, so that it's properly managed
        via output sync.
     6. gettimeofday is not portable.  Also, it's not really the best
        option for timing things because (due to NTP etc.) it can change
        (by that I mean that if it reports 10s elapsed it might not be
        that 10s really elapsed).  Using a monotonic clock is better,
        although that's also not portable.  But if we have to be
        non-portable maybe we should try to get an accurate accounting.
        On the gripping hand maybe it's not that important to be
        absolutely accurate.

You mentioned something about trying to send the start time through the
environment but I don't see any code to that effect here; how were you
doing that?