We're still doing PGO based on non-e10s, so updating the summary for that. I expect we're leaving perf gains (at least in IPC code and child process startup paths) up for grabs by not fixing this, so adding some flags to radar this for perf / prioritization.

I'm investigating. Off-hand it looks like we're not writing a separate file when e10s is turned on, perhaps because of sandboxing, or perhaps llvm is trying to write to the same file for the child process as well, or something.

I have something working, but it depends on the work in bug 1542746. It does look like there are some perf wins on Windows here ( https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=e5ac79268e81fe143126dccc559de61ab8663fed&newProject=try&newRevision=dab915f464a6d9f493bd1eb58434576efa77df85&framework=1 ) that I think are caused by the e10s switch rather than bug 1542746, though I'm waiting on retriggers (there's a windows raptor/talos backlog) and there's some small issues with the infra pipeline for the work in bug 1542746 for linux64, so a bit early to draw firm conclusions - looks promising though!

https://hg.mozilla.org/mozilla-central/rev/8b110b9889c3

Backed out changeset 8b110b9889c3 as requested by Gijs.

Backout link: https://hg.mozilla.org/integration/autoland/rev/b047e2089a784e9e5d08e8057ac4bef6411bf47e

A few notes as I dig into this:

1. the current set of files output by the profiler is ambiguous - it's basically meant to use a pool of randomly named files to avoid filename conflicts between multiple runs.
2. it does not include the pid, so no way to see if a child process wrote anything
3. good news, we can use an env var to control this filename and make it include the pid
4. bad news, doing so shows the child process writes nada/nothing/niente.
5. turning off sandboxing seems like a red herring - I think there was something wrong with my windows setup (or perhaps with windows sandboxing around the time I wrote the patch or whatever). It makes no difference here atm (though it is of course possible that after fixing whatever the issue is we have right now, we'd still run into sandboxing)
6. profiles are dumped at exit and kept in memory
7. searching the web finds me http://mysql-qa.blogspot.com/2009/06/kill-exit-exit-and-issues-getting-gcov.html . Our child process uses _exit, as far as I can tell, presumably because there shouldn't be anything to do when it exits?
8. Annnnd looking for code in our codebase brings me to https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/dom/ipc/ContentChild.cpp#2334-2339 which brings me to bug 1460929.

Nathan, does that look right? Do we just want to expand that define so we don't _exit() in the profiling build, just like in coverage builds?

OK, I have a trypush that suggests the answer to the bottom of comment 15 is "yes", just need to tidy up patches...

https://hg.mozilla.org/mozilla-central/rev/4b78f4fb473c
https://hg.mozilla.org/mozilla-central/rev/93ae54d47ca4