android build time regression from gradle upgrade

[gaaclarke]

Looks like upgrading gradle caused longer build times. @GaryQian

introduction: https://github.com/flutter/flutter/pull/108472

skiaperf: https://flutter-flutter-perf.skia.org/e/?begin=1659047227&end=1659087427&keys=Xb12d712c6f83f93b8557268fca33047a&num_commits=50&request_type=1&xbaroffset=30168

[chinmaygarde]

This is being discussed in a chat thread at go/5cff96f5-d09f-4497-a239-9ebefe9fe3b7 to double check a few things. But there may not be anything we can do about this.

[GaryQian]

Related (previous regression): https://github.com/flutter/flutter/issues/103421

[GaryQian]

From https://flutter-flutter-perf.skia.org/e/?begin=1659047227&end=1659087427&queries=sub_result%3Ddebug_compile_after_edit_millis%26sub_result%3Ddebug_full_compile_millis%26sub_result%3Ddebug_second_compile_millis%26test%3Dhello_world_android__compile&xbaroffset=30168, It looks like second compile times are impacted, but have increased far less than initial compile times.

Arm seems to have seen a larger percentage regression than intel. Intel second compile times are only slightly impacted.

[GaryQian]

After running benchmarks locally, AGP version or gradle version does not seem to impact build times as seen in regression. It does not repro locally.

7.2AGP, 7.5Gradle:

    "debug_full_compile_millis": 9107,
    "debug_second_compile_millis": 3166,
    "debug_compile_after_edit_millis": 4522

    "debug_full_compile_millis": 8456,
    "debug_second_compile_millis": 3252,
    "debug_compile_after_edit_millis": 4491

    "debug_full_compile_millis": 8521,
    "debug_second_compile_millis": 3184,
    "debug_compile_after_edit_millis": 4459

7.0AGP, 6.7Gradle:

    "debug_full_compile_millis": 8986,
    "debug_second_compile_millis": 3297,
    "debug_compile_after_edit_millis": 4648

    "debug_full_compile_millis": 8502,
    "debug_second_compile_millis": 3244,
    "debug_compile_after_edit_millis": 4553

    "debug_full_compile_millis": 8862,
    "debug_second_compile_millis": 3204,
    "debug_compile_after_edit_millis": 4571

4.1.3AGP, 6.7Gradle

    "debug_full_compile_millis": 8580,
    "debug_second_compile_millis": 3149,
    "debug_compile_after_edit_millis": 4489

    "debug_full_compile_millis": 8862,
    "debug_second_compile_millis": 3234,
    "debug_compile_after_edit_millis": 4540

    "debug_full_compile_millis": 9188,
    "debug_second_compile_millis": 3079,
    "debug_compile_after_edit_millis": 4654
    ```

[zanderso]

Is there a cache on CI that we'd need to update? @keyonghan might remember.

[keyonghan]

Is there a cache on CI that we'd need to update? @keyonghan might remember.

I doubt this is related to any packages caches, as this regression is consistent on every single build across all testbeds after the gradle version update. I am not sure how the gradle cache works. Let me know if there is anything you want to try from CI testbeds re gradle cache, etc. /cc @GaryQian

[zanderso]

@GaryQian Does this repro locally if you remove $HOME/.gradle between runs.

Could something like this be related: https://github.com/flutter/flutter/issues/84868 ?

[GaryQian]

Cleaning up .gradle on each run does indeed bring the debug_full_compile_millis local build time from ~8600ms -> ~9500ms. If this test is indeed run hermetically, the android/.gradle directory should not be there on initial run, but in practice, this test is just run in the examples/ dir. This means that if another test builds the app, flutter clean fails to remove the .gradle dir and thus causes increased build time.

This doesn't seem to be the direct cause of this regression, but we can still delete .gradle to make this test more hermetic. If build times do not change, then the existence of .gradle did not cause the regression.

[GaryQian]

This is an area where we don't actually have metrics to track the work dependencies does on initial compile only and gets cached. I created https://github.com/flutter/flutter/pull/109177 which adds additional benchmarks to track initial vs full compile times.

[chinmaygarde]

Looks like something we can't really address. Should we close this as WAI?

[zanderso]

We can leave this open to track the benchmark refactor in https://github.com/flutter/flutter/pull/109177. I'll retitle the issue.

[GaryQian]

This has been landed in https://github.com/flutter/flutter/pull/109177

[github-actions[bot]]

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.