Profiler-instrumentation of the startup time

Profiler-instrumentation of the startup time.

Before the instrumentation, startup time wasn't reported in profiler data.

Profiling it will allow the genre of detailed analysis of the startup time via jankiness investigations.

This change requires temporarily initializing tracking earlier than usual. Thie will either removed once the investigations complete, or will be officially converted to permanent code.

BUG=453640
Committed: https://crrev.com/1ebb11710e08d51fa99836190edc3db28dffc136
Cr-Commit-Position: refs/heads/master@{#314179}

[vadimt, 2015-01-30 01:45:52]

vadimt@chromium.org changed reviewers:
+ asvitkine@chromium.org, isherman@chromium.org

[vadimt, 2015-01-30 01:47:06]

asvitkine@, isherman@, please both provide approvals before I go to the OWNER

[Ilya Sherman, 2015-01-30 03:01:17]

LGTM, though I wonder why we previously did not instrument this code, and
whether it was for performance reasons.  It might be useful to discuss with
jar@.

[Alexei Svitkine (slow), 2015-01-30 14:09:23]

https://codereview.chromium.org/866403008/diff/1/chrome/app/chrome_main.cc
File chrome/app/chrome_main.cc (right):

https://codereview.chromium.org/866403008/diff/1/chrome/app/chrome_main.cc#ne...
chrome/app/chrome_main.cc:74: tracked_objects::ScopedTracker::Enable();
Does this actually work?

My understanding (but maybe I'm wrong) is this code is n chrome.exe, while the
rest of the code is in chrome.dll.

I might be wrong, but I thought they linked in their own copies of 'base'' - so
calling this at this stage will not affect the one in the dll. If that's the
case, then you may need to call the copy of this function that's in the dll -
e.g. similar to how DumpProcessFunction is called above.

But as I said, it is possible that I'm wrong. Can you check the above?

[vadimt, 2015-01-30 16:14:47]

https://codereview.chromium.org/866403008/diff/1/chrome/app/chrome_main.cc
File chrome/app/chrome_main.cc (right):

https://codereview.chromium.org/866403008/diff/1/chrome/app/chrome_main.cc#ne...
chrome/app/chrome_main.cc:74: tracked_objects::ScopedTracker::Enable();
This works  both in Debug and Release builds.

[Alexei Svitkine (slow), 2015-01-30 16:19:00]

Thanks for double-checking! LGTM

[vadimt, 2015-01-30 16:20:04]

vadimt@chromium.org changed reviewers:
+ cpu@chromium.org

[vadimt, 2015-01-30 16:20:05]

cpu@chromium.org: Please review

[vadimt, 2015-01-30 16:21:07]

jar@, FYI

[Ilya Sherman, 2015-01-30 21:13:14]

On 2015/01/30 16:21:07, vadimt wrote:
> jar@, FYI

Jim isn't really looking at Chromium code reviews anymore.  I'd recommend
emailing him directly, or possibly catching him on chat.

[vadimt, 2015-01-30 22:03:14]

IMHO, this is not worth bothering jar@.

One of changes I've made affects only Canary.

The other will effectively change nothing (in above-Canary builds).
tracked_objects::ThreadData::Initialize() gets called very early anyways, before
any existing call tries to do anything with ThreadData:
 	tracked_objects::ThreadData::Initialize()	C++
 	task_profiler::AutoTracking::AutoTracking()	C++
 	ChromeBrowserMainParts::ChromeBrowserMainParts()	C++
 	ChromeBrowserMainPartsWin::ChromeBrowserMainPartsWin()	C++
 	chrome::ChromeContentBrowserClient::CreateBrowserMainParts()	C++
 	content::BrowserMainLoop::Init()	C++
 	content::BrowserMainRunnerImpl::Initialize()	C++
 	content::BrowserMain()	C++
 	content::RunNamedProcessTypeMain()	C++
 	content::ContentMainRunnerImpl::Run()	C++
 	content::ContentMain()	C++
>	ChromeMain()	C++

I just move it earlier so that the new Canary-only code could work. Shouldn’t
cause perf problems.

BTW, I found and fixed a bug (see the second upload). Without this, Main thread
would be named incorrectly.

[jar (doing other things), 2015-01-30 22:21:11]

On 2015/01/30 03:01:17, Ilya Sherman wrote:
> LGTM, though I wonder why we previously did not instrument this code, and
> whether it was for performance reasons.  It might be useful to discuss with
> jar@.

I suspect it was an oversight (bug?).... but I both can't be sure.  

I can only be sure that I don't remember any reason why we wouldn't have
instrumented the code.

[And although I try not to do much reviewing... I valiantly watch this stuff go
by... and look in when I can].

[vadimt, 2015-01-30 22:22:50]

Thanks jar@!

[cpu_(ooo_6.6-7.5), 2015-01-31 22:05:30]

lgtm

[vadimt, 2015-02-02 18:29:00]

The CQ bit was checked by vadimt@chromium.org

[commit-bot: I haz the power, 2015-02-02 18:30:02]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/866403008/20001

[commit-bot: I haz the power, 2015-02-02 20:15:47]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-02-02 20:16:49]

Patchset 2 (id:??) landed as
https://crrev.com/1ebb11710e08d51fa99836190edc3db28dffc136
Cr-Commit-Position: refs/heads/master@{#314179}

[oystein (OOO til 10th of July), 2015-02-02 22:38:59]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/864273003/ by oysteine@chromium.org.

The reason for reverting is: Reverting due to https://crbug.com/454534.