Enable high-res CPU profile sampling for app startup

[lukehutch]

Use case

Right now the CPU profiler in DevTools has to be manually started. You can ask it for any samples that may have been captured during startup, but they usually only cover a very brief window of time during startup.

Proposal

There needs to be an option to start high-res CPU profiling sampling automatically, as soon as the app is started up, so that the startup activity can be fully profiled.

[darshankawar]

Thanks for the report @lukehutch I think this would belong to devtools repo, so transferring it there.

[kenzieschmoll]

You can do this today:

1. Run your flutter app with --start-paused (for a dart app the flag is --pause-isolates-on-start)
2. Open the DevTools URL that is printed to CLI and go to the CPU profiler page
3. Change the Sampling rate dropdown to "high"
4. Resume your app and let it complete starting up.
5. Then in the CPU profiler page, select the "Profile app startup" button

If you want to see more CPU samples outside of the ones captured by the AppStartUp UserTag, you can load all available samples by clicking the "Load all CPU Samples" button.

It is important to note that the app startup samples here are only for Dart code and do not contain any information about native activity before the Dart VM was started.

Consider using Fluttter's --trace-startup flag:

--trace-startup           Trace application startup, then exit, saving the trace to a file.
                          By default, this will be saved in the "build" directory. If the
                          FLUTTER_TEST_OUTPUTS_DIR environment variable is set, the file
                          be written there instead.

[lukehutch]

@kenzieschmoll Thanks for explaining this. It would definitely be great to have an easy-to-find doc page on this, thanks for creating that other issue.

I would love to see all the steps you covered automated into a single "Profile app startup" action in VS Code (or other IDE). I suspect the IDE does not have a way to ask DevTools to start or stop profiling, so even if the IDE could start the application with --start-paused, and then unpause the app via the debugging API, it would not be able to automate those steps. Is this a correct assumption? What would need to be added to DevTools to automate this whole process?

[lukehutch]

@kenzieschmoll I ran into a problem with this: --start-paused does pause in the debugger on startup, but then I get a warning that profiling performance may not be indicative unless I run in profile mode. However, running with --start-paused --profile fails to show the Main isolate is paused in debugger notification at the top of the screen, with the resume button. So the app starts, pauses, and can't be resumed if built in profile mode.

[kenzieschmoll]

Agreed this is confusing messaging and a sticking point. We should have a way to automate this as you suggested, likely with a command line flag that we can use from the IDEs.