Repository navigation
Provide FrameTiming flush mechanism #64808
Description
Currently, multiple FrameTimings are batched by the engine so it's hard for the framework to precisely control when to start and stop FrameTiming monitoring. That could make the benchmark either count some old frames before the profiling that it shouldn't count, or miss some frames in the end of profiling. (#64780 is a workaround to mitigate this.)
We should add an API to let the framework instruct the engine to reliably flush all pending FrameTimings to solve this issue.
Activity
chinmaygarde commentedon Aug 31, 2020
It seem like the ask here is to discard old traces before starting collection anew. If this is possible at all (AFAIK, there are thread specific trace buffers and there may not be a way to clear all of them at a specific time), we will need a Dart VM API to do this. The timeline mechanism may not tool for getting real time trace information from the VM. CC @rmacnak-google for thoughts on this.
chinmaygarde commentedon Aug 31, 2020
Elevating priority on this as fixing this should go a long way towards making benchmarks less flaky.
liyuqian commentedon Aug 31, 2020
The batching here doesn't involve Dart VM Timeline so I hope it can be done just in the engine.
rmacnak-google commentedon Aug 31, 2020
If the VM is configured to buffer the timeline events itself instead of forwarding them to the system tracer, it is possible to clear this buffer with clearVMTimeline. This should include thread-local buffers.
Though if a benchmark wants to compute its score by examining the timeline, I would recommend emitting events that show the scope of the benchmark and filtering based on the timestamps of those events rather than clearing the timeline itself. Clearing would remove context useful when someone manually investigates the benchmark, and clearing only works for discarding events that are too early and not for events that are too late.
kf6gpe commentedon Jan 11, 2021
As this is a new feature request, reprioritizing to reflect our current triage priorities.
3 remaining items
flutter-triage-bot commentedon Jul 8, 2023
This issue is assigned but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!
flutter-triage-bot commentedon Dec 4, 2023
This issue is assigned to @iskakaushik but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!
flutter-triage-bot commentedon Feb 8, 2024
This issue was assigned to @iskakaushik but has had no status updates in a long time. To remove any ambiguity about whether the issue is being worked on, the assignee was removed.
jonahwilliams commentedon Feb 12, 2024
We don't need to do this.
github-actions commentedon Feb 26, 2024
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.