Turning on debugProfileBuildsEnabled, debugProfileLayoutsEnabled, or debugProfilePaintsEnabled causes significant performance overhead, which is why these options are disabled by default. They do make the timeline more useful, though, and there's value in figuring out if we could enable these options by default.

Open questions:

• Are these options expensive because calling the timeline API so often is expensive?
• Or is the majority of the expense caused by the implicit runtimeType.toString() calls that happen to log the name of the RenderObject/Widget to the timeline?
• If it is the latter, could we use a kernel transformer to replace the runtimeType.toString() calls with the actual static string name of the RenderObject/Widget they are called on to make these options cheaper?

Even if we don't want to turn these options on by default, making them cheaper has the benefit that one can still make accurate performance statements from traces with these options enabled. Right now, traces with these options enabled only allow for relative statements (x is slower than y in the same trace).

/cc @dnfield @kenzieschmoll @jacob314