I would like it to be easy to use the profiler to debug performance issues either in tests or in code exercised by tests. Ideally it should be as easy as: ./mach mochitest path/to/test/browser_test_name.js --profile

This is what I currently do to profile a bc test. It's inspired from https://searchfox.org/mozilla-central/rev/be78e6ea9b10b1f5b2b3b013f01d86e1062abb2b/devtools/client/webconsole/new-console-output/test/chrome/test_render_perf.html#189-232 in which I added enabled stackwalking, and then it uses https://github.com/mstange/analyze-tryserver-profiles to symbolicate the profile before uploading it.

I believe Greg was just looking into this yesterday. Can you share what you were thinking on how to do this?

I was looking into this yesterday. Here is what I would love to do: Run: ./mach mochitest path/to/test/browser_test_name.js --profile Python would process the command line args, then kick off a Gecko process with a new pref like "testing.profiler.enabled" The mochitest JS initialization would then start the Gecko Profiler using the same code as: https://searchfox.org/mozilla-central/rev/be78e6ea9b10b1f5b2b3b013f01d86e1062abb2b/devtools/client/webconsole/new-console-output/test/chrome/test_render_perf.html#189-232 The test runs to completion. The mochitest tear down code dumps the file out to a temporary location, then Gecko exits. The python mach script would continue to run, and spin up a simple HTTP server that serves the profile. It then provides a link to perf-html.io to view the profile, e.g. http://perf-html.io/from-url/http%3A%2F%2Flocalhost%3A4242%2Fprofile.json Then the user can view the profile, and optionally share it through the perf.html interface if they need to, or download it. Python will run until ctrl-c is hit, where it will clean up the temporary profile. I took a stab at this yesterday, but didn't really understand the mochitest architecture enough to prototype it quickly.

There are also environment variables to start and stop the profiler with MOZ_PROFILER_STARTUP AND MOZ_PROFILER_SHUTDOWN=/path/to/profile.json But this only captures the main process, which doesn't have all the information that you would want.

(In reply to Greg Tatum [:gregtatum] [@gregtatum] from comment #3) Any idea of how you would handle getting symbols? Usually network access is forbidden during tests, and attempting to access the network triggers a crash, so if we do any network request to fetch system library symbols, we'll crash.

It crashes if Firefox does any requests, but I imagine it is fine if python test harness does it. That's what Talos does: https://searchfox.org/mozilla-central/source/testing/talos/talos/gecko_profile.py#110-201

This might be a good reference implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1425308