This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

Hi team! I was looking into a way to track local build times. I've noticed that BuildListener#buildFinished is now deprecated given that configuration-cache is enabled. What would be the best way to tackle this? Do you happen to know any other APIs for it? I feel like this approach might be a little bit too naive - and also it does not include configuration phase 🤔

tasks.configureEach { task ->
    if (task.name.startsWith("assembleDebug")) {
        println "Track start time"
        task.doLast {
            println "Track end time"
        }
    }
}

Running benchmarks is of course an option but I wanted to see an overall trend on a day-to-day develoment among devs.

Hi team, I have a team of 20 devs, we want to enable gradle build cache push for local development, so that when engineers open PRs we save on build time on CI machines as a means to reduce costs. On CI we already have push/pull enabled. Is there any issues with enabling push for build cache for local dev machines?

hi 🙂 is there a easy way to get the RAM and CPU usage of a Gradle build, preferably through Gradle Profiler?

Launching lib\main.dart on sdk gphone64 x86 64 in debug mode... Running Gradle task 'assembleDebug'... FAILURE: Build failed with an exception. * What went wrong: java.util.concurrent.ExecutionException: org.gradle.api.GradleException: Failed to create Jar file C:\Users\ICTFLARE\.gradle\caches\jars-9\25af9f93dc8b39fa0484de5e10be7606\gradle-7.3.0.jar.

org.gradle.api.GradleException: Failed to create Jar file C:\Users\ICTFLARE\.gradle\caches\jars-9\25af9f93dc8b39fa0484de5e10be7606\gradle-7.3.0.jar.

* Try:

Run with --stacktrace option to get the stack trace.

Run with --info or --debug option to get more log output.

Run with --scan to get full insights.

Get more help at https://help.gradle.org.

BUILD FAILED in 4s Error: Gradle task assembleDebug failed with exit code 1

Hi people, we have a medium multymodule android project (~200 modules) with convention plugins and plugins in buildSrc. We started with gradle profiling clean cached and clean non cached builds. Additionally measured the Gradle 8.8 update. While I'm thinking about what scenarios to cover more (any hints are welcome), I have next observations-questions: 1. The max of clean uncached build is 4-5 minutes but I do remember waiting 8-9 mins in AS. Should I care about the numbers I remember? Is it possible that profile builds by far from the memory longes builds? 2. The 8.8 Gradle wins over 8.7 with 10 seconds in the clean cached and loses 16 seconds in the clean uncached. I would say that is comparable and acceptable. What would be the breaking threshold for you? Should it be relative or absolute?

And any good resources or recommendations to follow/read?

Hi folks! I'm not that familiar with devlocity - I have .scandump file, is there anyway to view that without a Devlocity enterprise subscription?

I discovered https://github.com/gradle/gradle-profiler which is amazing! The scenarios file covers everything I want which is so refreshing compared to bodging together random Python scripts. It even has chrometrace output so I can open the results in Perfetto https://ui.perfetto.dev/#!/?s=76f73d00b1f5161a5bc7ba076fd529dba2a2cb5c7ec0240676699e7b5a98381d. Folks did a great job 😃

Hey folks what would be good way to profile the jvm used to run unit-tests? I tried running this using the gradle-profiler with async-profiler but I'm not sure if that leads to the test jvms being invoked with async-profiler enabled.

Greetings All, "An In-depth Look at Gradle's Approach to Faster Compilation" has the following footnote:

Assuming a non-JPMS build, which may affect certain details.

Does modularizing a build have any known performance impacts, positive or negative? For example, might module descriptor info be used to speed up ABI analysis for compilation avoidance when only a subset of the packages containing public API in a project are exported? Does

java.modularity.inferModulePath

add any significant overhead?

I'm trying to learn about our build performance. I have a particular build scan I'm looking to understand better (I don't know if build scans are shareable like that). More specifically I'm trying to understand the task parallelism (or rather the lack of it). Is this a good channel for that?

recently in past couple months, our project’s sync time has gone from 1-2 mins to upwards of 6 minutes. in some build scans ive noticed quite a gap between time to sync (6 mins) with the last visible task of :`prepareKotlinBuildScriptModel` . i have to assume its the IDE model being built, but the scans completely do not track that gap. is there ways to grab more detailed metrics on why a gradle sync takes 6 mins? the build scans do not actually reveal the gaps or what happens in between each marker

About profiler - the git checkout option - does it clean up deleted files? Let say I have commit where I delete some configuration files. And I do two scenarious - one with this files and one without. I wrote them with option git checkout. But I wonder now, if the checkout of newer commit also deletes files on filesystem.

But let me just run small gradle task locally and just see it

Also wonder does profiler runs scenarios in alphabetical order?

has anyone had issues with multiple daemons spinning up out of nowhere? I mean im not building in the IDE, essentially,

./gradlew --stop
No Gradle daemons are running.
./gradlew --stop
Stopping Daemon(s)
2 Daemons stopped

nonstop. killing java process resuscitates the daemons. these extra "zombie" daemons do not persist on next run, and force more daemons to run.