bug-make
[Top][All Lists]
Advanced

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

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


From: Tim Murphy
Subject: Re: [bug #40639] GNU Make with profiling information
Date: Wed, 27 Nov 2013 11:12:19 +0000

FWIW

As for profiling output, this should probably go to a file (possibly
with a .PID on the end) , not stdout .....unless..... you start to
embrace the idea of structured output for everything that make
produces.

I have used XML before and it has advantages, not the least of which
is that it is somewhat robust in the face of corruption and that does
happen. I prefer JSON though because it's more readable and it's very
easy to parse.

On 27 November 2013 07:56, Eddy Petrișor <address@hidden> wrote:
>
> Pe 25.11.2013 11:09, "Reinier Post" <address@hidden> a scris:
>
>
>> > > Can't this functionality be provided by a wrapper $SHELL?
>> > > Sure, it's an extra exec(),
>> > > but it will keep the make code base simpler.
>> >
>> > I'm not sure if I understand what you mean. Do you mean wrapping all
>> > target invokes in a $SHELL?
>>
>> Yes; something line /usr/bin/time.
>
> Not on Windows.
>
>> > If that's the case, you don't get the actual/real-time measurement, and
>> > that might skew your profiling information.
>>
>> True.  Hnow how much of a difference does it make?
>
> Depends on how badly the build system is written. And that's what the target
> of the profiling is, finding out how bad is it. I feel that penalising the
> most exactly the build systems that need the least the slow down it's bad
> design.
>
>> > I have some build systems that can take easily over 12 hours to do a
>> > full build (several thousands of elfs in recursive
>> > make calls - I know that's bad, I am working on it), so any extra time
>> > waste just for the measurement can mean
>> > significant delays in getting the results.
>>
>> If it's 15 minutes, they are not the thing you want to optimize first.
>> The build is probably running overnight anyway.
>
> If it's a live/production system, then any unknown slow down time might not
> be acceptable.
>
>
> _______________________________________________
> Bug-make mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-make
>



-- 
You could help some brave and decent people to have access to
uncensored news by making a donation at:

http://www.thezimbabwean.co.uk/friends/



reply via email to

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