wrap adding this extension in a
assert(() {
...
return true;
}())
as it only does something useful in debug builds.

or switch all uses of debugProfileBuilds to use profile(...) instead of assert(...)

and change the name of the flag to indicate to clarify that it also works in profile builds.

I'd like this to be accessible from both debug and profile builds. For now, I may wrap this in an assert - so it's just available from debug builds - and plan to move at some point to using profile() and changing the callsites.

In the interim, perhaps I'll change the text name re register it as to something that won't need to change when it's also available in profile mode. So, from debugProfileBuilds to something like profileWidgetBuilds or similar.

debugProfileBuildsEnabled should never be enabled in profile builds. It destroys performance. There's no point in running it in profile builds, you won't get useful data.

Many performance problem diagnosis tools are still useful even though they hurt performance while enabled. For example, a CPU profiler that requires significant instrumentation to gather data.

We just need to make sure that users are clear when they have turned on service extensions in profile builds that make their performance non-representative of release performance. Perhaps we need to add a "SLOW" banner. :)

It's not that it's non-representative of release performance, it's that the numbers aren't even proportional to release performance. The numbers are of zero value. All you get out of this flag is a bunch of stack traces, essentially. It's useful for knowing what work is happening, but not for any sort of performance-based tracking. That's why the flag is disabled in profile builds. You don't get anything better running it in profile builds than in debug builds.

Profile builds exist only so that you can get valuable release-proportional performance metrics. We shouldn't do anything in profile builds that muddles that message. If someone just wants to debug, they should use debug mode.

It's useful for knowing what work is happening

I'd see it as an additional tool to use when trying to track down a performance issue. Say you're running in profile mode - for representative performance - and saw an issue. You could enable debugProfileBuildsEnabled, grab the output of a frame or two, and disable debugProfileBuildsEnabled. It would show you want that frame was doing, even if the specific perf from that frame was no longer reliable.

This PR doesn't switch the flag to being available in profile mode - it's still just in debug. I think we should just evaluate how useful it is in that mode for now.

@Hixie knowing what work is happening is exactly what users often need to do to solve the simple performance problems we are tackling this quarter. I agree that they can diagnose those issues just fine in debug mode. The problem is the user doesn't realize what issue a certain portion of their app has until they use a profile build. Using a debug build to determine performance issues, users will become concerned about performance issues that are not actually issues in release builds risking premature optimizations.

There is another solution if users are confused by being able turn on performance debugging tools in profile build. We can work on making it faster for a user to switch back and forth between release and profile builds potentially keeping both running at the same time on the same device within a single application on Android.

any reason this isn't just
getter: () async => debugProfileBuildsEnabled,

?

No reason - I'll simplify this.

typo in comment. Remove "to the"

will fix