Skip to content

2x regression in total_ui_gc_time for backdrop_filter_perf_ios__timeline_summary #159337

Closed

Activity

  1. added
    c: performanceRelates to speed or footprint issues (see "perf:" labels)
    on Nov 22, 2024
  2. gaaclarke commented on Nov 22, 2024

    @gaaclarke
    MemberAuthor

    @justinmc can you take a look at this regression please? It seems something in that PR has increased the garbage are generating. Maybe there is some way we can tweak it to make less garbage?

  3. matanlurey commented on Nov 22, 2024

    @matanlurey
    Contributor

    @justinmc can you take a look at this regression please? It seems something in that PR has increased the garbage are generating. Maybe there is some way we can tweak it to make less garbage?

    I took a quick look before a meeting - there is a significant amount of Sets being allocated and filled per build() now that were not before - if I had to guess it is related to that.

  4. goderbauer commented on Nov 26, 2024

    @goderbauer
    Member

    @bleroux Maybe we should revert that change?

  5. added
    P1High-priority issues at the top of the work list
    on Nov 26, 2024
  6. bleroux commented on Nov 27, 2024

    @bleroux
    Contributor

    @goderbauer Thanks for pinging me.

    I filed #159546 which optimizes the Set computations added in #159072.

    Nonetheless, it is not clear to me why this change would impact this particular benchmark because there are no InkWell involved in this benchmark.
    The same graph for Android was not impacted, see https://flutter-flutter-perf.skia.org/e/?begin=1732616899&end=1732703299&queries=sub_result%3Dtotal_ui_gc_time%26test%3Dbackdrop_filter_perf__timeline_summary.

    Could it be possible that a change merged some hours before my PR leads to this regression?

    I ask this because this benchmark uses Image.blur intensively and the following engine roll landed some hours before my PR and it contains a blur related change.

    To see if this theory is valid, we should probably revert #159072 (and before revert #159203 which depends on it).
    Doing so we will see, if the perf regression is gone or not.

    Let me know it it makes sense. If it does, thanks to initiate the revert process by starting with #159203 and then #159072.

  7. gaaclarke commented on Nov 27, 2024

    @gaaclarke
    MemberAuthor

    Could it be possible that a change merged some hours before my PR leads to this regression?

    I don't think so, but I think you are right to be skeptical that your PR caused this change. I saw similar regressions as a result of #159228. That PR made the framerate faster on iOS, so more garbage was being generated per time. The weird thing is that that PR landed a day after yours did.

  8. zanderso commented on Dec 2, 2024

    @zanderso
    Member

    It looks like the flagged change was reverted, so I'll go ahead and close this. Feel free to re-open if I'm mistaken.

  9. bleroux commented on Dec 3, 2024

    @bleroux
    Contributor

    @gaaclarke I reverted my PR several days ago (last Tuesday). Due to thanksgiving there were few commits until Monday. Now we have some data and the regression seems to be still there (my PR was flagged with a total_gc_gpu_time of 1.5, but since my revert there is one occurrence at 2.03, one at 1.66 and several significantly above the previous average.
    I don't know the policy about tackling those perf regressions, especially if the issue should be reopened.

  10. gaaclarke commented on Dec 3, 2024

    @gaaclarke
    MemberAuthor

    @gaaclarke I reverted my PR several days ago (last Tuesday). Due to thanksgiving there were few commits until Monday. Now we have some data and the regression seems to be still there (my PR was flagged with a total_gc_gpu_time of 1.5, but since my revert there is one occurrence at 2.03, one at 1.66 and several significantly above the previous average. I don't know the policy about tackling those perf regressions, especially if the issue should be reopened.

    Okay, thanks for doing that. I would go ahead and reland your PR and not worry about it. I'm not sure what is going on. Usually we try to catch stuff as it comes it. It becomes difficult to manage otherwise. This time we got weird signals though. FWIW GC time is kind of a secondary metric; like I mentioned, faster frame times can lead to its increase, which is actually a good thing. We'll keep an eye on it.

  11. github-actions commented on Dec 17, 2024

    @github-actions

    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 -v and a minimal reproduction of the issue.

  12. locked as resolved and limited conversation to collaborators on Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1High-priority issues at the top of the work listc: performanceRelates to speed or footprint issues (see "perf:" labels)team-frameworkOwned by Framework teamtriaged-frameworkTriaged by Framework team

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions