search

flutter / devtools

Performance tools for Flutter
https://flutter.dev/docs/development/tools/devtools/
BSD 3-Clause "New" or "Revised" License
1.58k stars 326 forks source link

Highlight GCs that occur in the middle of frames #2724

Open jacob314 opened 3 years ago

jacob314 commented 3 years ago

We should emphasize GCs that occur in the middle of a frame or delay a frame from starting on time. The highlighting should show up in both the performance and memory page. These GCs are much more noteworthy while other GCs may just indicate everything is WAI and Flutter is effectively running GCs between frames. Fyi: @terrylucas @kenzieschmoll, @dnfield This is a feature at the boundary of the memory and timeline functionality.

dnfield commented 3 years ago

The question is what does a user do about this?

jacob314 commented 3 years ago

Example UJ: User notices a large GC occurred that blocked frame rendering for 100ms while using the timeline to investigate a framerate issue. User goes to the memory page and reproduces the problem and uses the memory page to diagnose and fix the source of the excessive memory usage. In the easy case, there were some unexpectedly large allocations shortly before the GC that can be optimized. In the harder case, the user knows that their apps high memory usage is impacting performance and so work to optimize overall memory usage will help avoid dropped frames.

Concretely a user can take a look at a snapshot shortly before the costly gc is triggered and a snapshot after it is triggered. Looking at objects that were freed by the GC they notice the source of the memory spike (for example lots of Map and List data objects from parsing an overly large json file or using a SQL plugin that was sending much more data to dart than the user expected. Fyi @InMatrix @cobblest. We can create a sample app that reproduces this by expensive JSON parsing or sending too much data from a SQL plugin.

InMatrix commented 3 years ago

We need to work on the user journey here.

User notices a large GC occurred that blocked frame rendering for 100ms while using the timeline to investigate a framerate issue.

Users probably won't notice GCs in the beginning. A more plausible starting point is that the user notices some dropped frames from their apps. Then, the user probably opens to the Timeline page if they knew about the tool. Otherwise, they're more likely to look for something expensive in their code. The key challenge here seems to be about how to help the user link issues they could observe from the Timeline page to the root cause that might be present in the Memory page.

dnfield commented 3 years ago

IME it's very unlikely that a GC blocks UI, let alone for that long. It's much more likely to get a compaction running in parallel, which can cause contention but shouldn't block.

cobblest commented 3 years ago

Can this be captured by the automatic snapshots?

jacob314 commented 3 years ago

There is a chance automatic snapshots will work for this case. I agree with Dan that the next step is we need to validate there are organic cases of this issue. I've heard a report but I haven't analyzed the CPU and memory snapshot myself to verify it is accurate.

jacob314 commented 3 years ago

Btw one challenge is you better make sure automated snapshots are not enabled before you identify there is a dropped frame issue as the automated snapshots will make it look like you do have a dropped framed issue as computing snapshots is expensive.