Performance profiling documentation should mention buffer size

[curt-weber]

Steps to reproduce

1. Run a performance test using: https://docs.flutter.dev/cookbook/testing/integration/profiling
2. Save the results
3. Notice that the frame count is low

Suggest in the documentation that --endless-trace-buffer or --trace-startup (or both) should be specified to flutter drive or the summary won't include the totality of the test.

Expected results

The frame count should match the amount of frames pumped during the test.

Actual results

The frame count (due to the ring buffer), will be much lower than the amount of frames pumped. Even for short tests (<5 seconds) the frame count is still too low.

Code sample

Code sample

Performance profiling

Screenshots or Video

Screenshots / Video demonstration

[Upload media here]

Logs

Logs

[Paste your logs here]

Flutter Doctor output

Doctor output

Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.19.1, on Microsoft Windows [Version 10.0.19044.3930], locale en-US)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.3.5)
[√] Android Studio (version 2021.3)
[√] VS Code (version 1.87.0)
[√] Connected device (3 available)
[√] Network resources

• No issues found!

[huycozy]

Hi @curt-weber, this is suited to website repository for better support there. Transferring the issue.

[jonahwilliams]

If you have a single test per driver file, this is a reasonable thing to do. but you might also have multiple test cases that are only attempting to measure a specific workload. So this is a reasonable thing to do in general. If you use flutter_driver you will also need to includePreviousEvents when tracing

[curt-weber]

Originally I wasn't sure whether to file this as a bug or a documentation improvement. When testing this I was using just 1 test/1 file/1 driver. What I noticed was onReportTimings was capturing the whole duration, but the flutter driver Timeline was capturing just the last 2-3 seconds of a 10 second test. This was crucial since the worst build/worst rasterize happened towards the end of the first second, which meant the report was making the performance appear better than it was. Perhaps it would be good to be able to specify timeline filtering so the ring buffer during performance runs are only filled with relevant events, and then you could be confident the whole tests performance was captured.