Repository navigation
50ms GC loading Weather demo #3804
Description
This trace: #3082 (comment)
...includes a 46-54ms GC at t=87,611.486 ms.
To reproduce, open the gallery app and run the Weather demo.
This trace: #3082 (comment)
...includes a 46-54ms GC at t=87,611.486 ms.
To reproduce, open the gallery app and run the Weather demo.
Activity
eseidelGoogle commentedon May 23, 2016
FYI @a-siva, happy to help someone who's interested in GC issues to repro.
rmacnak-google commentedon May 25, 2016
The longest GC I see running the gallery app on a Nexus 4 is 26 ms. With some extra timeline events, I see 18 ms of this is spent processing weak handles, with 952 of 1012 being finalized. How expensive is destructing Path, Picture, Paragraph, and friends?
abarth commentedon May 25, 2016
They might be taking time. We can move them to a finalization queue and destruct them in small chunks. Most of them can be destructed on a background thread.
eseidelGoogle commentedon May 25, 2016
Sounds like we should check in these extra timeline events. :) Makes it clear when it's flutter's bug to fix :D
abarth commentedon May 25, 2016
@rmacnak-google Let's chat tomorrow about how best to hand off the set of things that need finalization from the GC to the embedder.
rmacnak-google commentedon May 25, 2016
Extra timeline events in dart-lang/sdk@18c87ab.
Current thought is for the VM to invoke the finalizers on a background thread.
eseidelGoogle commentedon May 25, 2016
@chinmaygarde didn't we have a threading issue with finalizers before? Could this new proposal be an alternate solution?
chinmaygarde commentedon May 25, 2016
@eseidel If you are referring to flutter-team-archive/engine@3a5dd866, that was just the modification of the reference count of the
DartWrappablefrom any thread that was not theui_thread. I believe this is a bit different.abarth commentedon May 25, 2016
@eseidelGoogle The solution for that issue is what makes this approach attractive for this issue. Given that we need to be prepared for finalizers to be called on any thread, the VM might as well call them on a background thread instead of the UI thread to avoid janking the UI thread.
Roll Dart to pick up: (#2778)
eseidelGoogle commentedon Jul 19, 2016
@abarth says this is solved.
github-actions commentedon Aug 15, 2021
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.