Make ninja display elapsed compile time by default.

Make ninja display elapsed compile time by default.

This will help debug slow or hanging compiles.

BUG=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=269042

[ghost stip (do not use), 2014-05-06 18:43:34]

lgtm, format is in
https://github.com/martine/ninja/blob/8fe13f5dabfc5e1581d2fc82fd7f535bdd70ce0...

[Paweł Hajdan Jr., 2014-05-08 07:02:02]

The CQ bit was checked by phajdan.jr@chromium.org

[commit-bot: I haz the power, 2014-05-08 07:02:40]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/phajdan.jr@chromium.org/268833006/1

[commit-bot: I haz the power, 2014-05-08 07:03:31]

Change committed as 269042

[Nico, 2014-05-13 09:34:11]

It'd been good to have a tracking bug that explains what exactly you're trying
to debug. (In general, CL descriptions should answer "why?")

Will these be undone once you're done debugging what you're debugging?

It's natural that different people want to add various bits of logging to the
build about they think are interesting. The end state of this is build output
that contains far too much information, which is an undesirable end state. So
build output should only get longer temporarily, while things are being
debugged.

[Nico, 2014-05-16 00:42:58]

ping


On Tue, May 13, 2014 at 2:34 AM, <thakis@chromium.org> wrote:

> It'd been good to have a tracking bug that explains what exactly you're
> trying
> to debug. (In general, CL descriptions should answer "why?")
>
> Will these be undone once you're done debugging what you're debugging?
>
> It's natural that different people want to add various bits of logging to
> the
> build about they think are interesting. The end state of this is build
> output
> that contains far too much information, which is an undesirable end state.
> So
> build output should only get longer temporarily, while things are being
> debugged.
>
> https://codereview.chromium.org/268833006/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Paweł Hajdan Jr., 2014-05-16 13:49:14]

On 2014/05/13 09:34:11, Nico (on vacation Fri May 16) wrote:
> It'd been good to have a tracking bug that explains what exactly you're trying
> to debug. (In general, CL descriptions should answer "why?")
> 
> Will these be undone once you're done debugging what you're debugging?
> 
> It's natural that different people want to add various bits of logging to the
> build about they think are interesting. The end state of this is build output
> that contains far too much information, which is an undesirable end state. So
> build output should only get longer temporarily, while things are being
> debugged.

Please note it's harder to notice comments on closed CLs.

For now I don't have plans to revert this.

This helps debug any build slowness or timeouts, and will be useful for future
cases.

If possible, please move the discussion of the CL so it's easier to follow.

[Nico, 2014-05-19 21:26:08]

On Fri, May 16, 2014 at 6:49 AM, <phajdan.jr@chromium.org> wrote:

> On 2014/05/13 09:34:11, Nico (on vacation Fri May 16) wrote:
>
>> It'd been good to have a tracking bug that explains what exactly you're
>> trying
>> to debug. (In general, CL descriptions should answer "why?")
>>
>
>  Will these be undone once you're done debugging what you're debugging?
>>
>
>  It's natural that different people want to add various bits of logging to
>> the
>> build about they think are interesting. The end state of this is build
>> output
>> that contains far too much information, which is an undesirable end
>> state. So
>> build output should only get longer temporarily, while things are being
>> debugged.
>>
>
> Please note it's harder to notice comments on closed CLs.
>
> For now I don't have plans to revert this.
>

Please create one, then. We shouldn't add unnecessary stuff indefinitely.


> This helps debug any build slowness or timeouts, and will be useful for
> future
> cases.
>

"potentially useful in the future" is the excuse for all logging. It leads
to too much logging.


> If possible, please move the discussion of the CL so it's easier to follow.
>

Move it where? As I said, a tracking bug would've been good, then I
would've asked there. As is, this is the best place for this discussion, as
it's easily findable from blame output.


>
> https://codereview.chromium.org/268833006/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Paweł Hajdan Jr., 2014-05-21 09:27:36]

Please see https://goto.google.com/ktppi

[Nico, 2014-05-21 17:53:56]

On Wed, May 21, 2014 at 2:27 AM, <phajdan.jr@chromium.org> wrote:

> Please see https://goto.google.com/ktppi


That's just a link to a mail saying "I'm about to land this change". It
doesn't explain why the change is being made, and for how long.

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Nico, 2014-07-02 19:40:44]

We talked about this off-list and Pawel pointed to a few bugs where he had hoped
that this will help. I starred these bugs and haven't seen an update on any of
them in the last 5 weeks. So I'd like to back this change back out again.

[Nico, 2014-07-17 20:36:25]

On 2014/07/02 19:40:44, Nico (away) wrote:
> We talked about this off-list and Pawel pointed to a few bugs where he had
hoped
> that this will help. I starred these bugs and haven't seen an update on any of
> them in the last 5 weeks. So I'd like to back this change back out again.

Going once, going twice…

[Nico, 2014-07-18 23:20:24]

A revert of this CL has been created in
https://codereview.chromium.org/405733002/ by thakis@chromium.org.

The reason for reverting is: This made the build pages more noisy and happened
to not be as useful as hoped in practice..

[Nico, 2014-07-18 23:22:40]

On 2014/07/18 23:20:24, Nico (away) wrote:
> A revert of this CL has been created in
> https://codereview.chromium.org/405733002/ by mailto:thakis@chromium.org.
> 
> The reason for reverting is: This made the build pages more noisy and happened
> to not be as useful as hoped in practice..

…oh sorry, just noticed that your rietveld name says that you're away until
7/20. I'll wait a few more days with landing that, then.

[jabdelmalek, 2014-08-18 19:12:19]

I disagree with the revert of this cl. Yes in general we don't want noisy
output. But having the times before was comparable to how we print test
runtimes.

Especially with the code yellow and trying to analyze why windows compile steps
are too slow, losing this information has made things harder to debug across
aggregate cls.

I'll revert the revert for now since we need this data. We can discuss if anyone
wants to revert that.

[ukai, 2014-08-19 01:54:28]

On 2014/08/18 19:12:19, jabdelmalek wrote:
> I disagree with the revert of this cl. Yes in general we don't want noisy
> output. But having the times before was comparable to how we print test
> runtimes.
> 
> Especially with the code yellow and trying to analyze why windows compile
steps
> are too slow, losing this information has made things harder to debug across
> aggregate cls.
> 
> I'll revert the revert for now since we need this data. We can discuss if
anyone
> wants to revert that.

I'm planning to upload .ninja_log to cloud storage, so that we could analyze why
compile steps slow offline.
What do you think?

https://groups.google.com/a/chromium.org/d/topic/hackability-cy/q-w99clsfMs/d...