What could cause this sort of spike to occur? Is this a sign the daemon wasn’t “warm” enough (there were 6 warm-ups for each scenario in this case)

Hello again 👋🏻 I’m interested in tagging builds made with a cold daemon so that I can exclude them in GE Trends. Is there a recommended way of doing this? I couldn’t find any properties about this

Hey! I'm wondering if there's any reported issue related to Gradle 7.4 performance. I ran some benchmarks with Gradle Profiler and in some scenarios the build time got way slower. 🧵

Hi, I have two

Sync

tasks that each extract files an archive into a directory. Each task has a different archive as input and a different output directory, so they should be completely independent, but they’re running sequentially, rather than in parallel. Is this expected? 🧵

Am I understanding correctly that "gradle-profiler" does not create flamegraph for configuration phase? Only for execution?

If I run

./gradlew build

for my project it succeeds. If I run

gradle-profiler --project-dir . --benchmark build

it fails on varying "could not resolve" or "could not download" artifact exceptions. The project in question is configured to exclusively use an internal Nexus proxy repo via a

dependencyResolutionManagement

block in settings.gradle.kts, which notably is incubating. Trying gradle-profiler on a different project, one that is configured to use Maven Central directly, works without issue. Could it be that gradle-profiler doesn't yet support

dependencyResolutionManagement

configuration, or is there something else I should do to troubleshoot this issue?

I have optimized our build to a point which I am comfortable with when it comes to CI, but in IntelliJ stuff can always go faster. I have a kotlin multimodule project. Any configuration hints inside gradle that affects the time-to-test (how long does it take to run a test after I change the code) in IntelliJ when I use "build using gradle" option for a kotlin project? We use latest kotlin and in gradle we use build caching and parallel execution.

When using Gradle profiler, can I access to the profiler informations within the build itself? Ex, I'd like to get the scenario's name and the current run info (warmup, measured, run number) so I can add custom tag in our build scan.

What would be the best way to capture heap dump on Gradle daemon OOM while running gradle-profiler scenario? I suppose adding into

gradle.properties

org.gradle.jvmargs="-XX:+HeapDumpOnOutOfMemoryError"

. I see heapdump option only for profiling case.

Is there any way I can avoid daemons to be stopped by gradle-profiler when running a benchmark scenario?

I wonder - does it noticeably improve performance pointing

--project-cache-dir

into ram disk? 🤔

Is it possible to use

--offline

with gradle profiler? I want to avoid hitting remote build cache.

So if I were to cancel a build, that moves the gradle daemon status to “CANCELLED”. It takes some time before this changes to “IDLE” . Now if I start a new build before this state change happens, gradle spawns another daemon. Would this have an impact on the build performance on my local machine? Is there a way to ensure gradle reuses the same daemon instead of creating a new one?

Hi Team, Currently I am working in the improvisation of our framework performance. Initial build configuration occupies around 3 .15 seconds .. My requirement is to reduce the initial kickoff time .

Anyone can help me on this part .. If anyone needed more details on this will share with you guys…

https://docs.gradle.org/current/userguide/performance.html I referred this site and modified the org.gradle.configureondemand=true org.gradle.caching=true But no luck on this changes

How does gradle get the default org.gradle.workers.max? I was wondering why my builds seemed so slow when I switched to linux, and it seems because thats defaulting to 8 rather then 64, like it does on windows. Tested with

println project.getGradle().getStartParameter().getMaxWorkerCount()

This message was deleted.

Hey all! I’m new here, just learned this server exists. I’m trying to figure out how to speed up my team’s tests, and I’ve run into a weird thing. When running a dead-simple test (literally

assertTrue(true)

in a new class with nothing else in it in our environment, it takes 3.5 minutes to run from clean, and 1.5 minutes to run once built (or if I make a tiny change like changing the test to

assertFalse(false)

. The first thing I’m going for is the configuration step which takes almost a full minute on project

:

. No additional context. Does that mean the root project or something? It doesn’t break out into categories in the results of

--profile

or

--scan

and we don’t seem to have any projects explicitly named

:

as far as I’ve been able to tell

I'd like to reduce the max test executors that can be spawned, without reducing workers in general. Is that possible? My goal is to limit memory usage. Reducing workers would also affect other steps of the build, as I understand

Hi! We are investigating the memory usage of Gradle as we are seeing the Gradle deamon heap being exhausted, causing many GCs and ultimately slowing down the build. We want to identify tasks that are potentially consuming too much memory. Around 50% of the memory is needed for the configuration phase which means the other 50% is used for execution which has proven to be too little. An experiment we are conducting is to run all tasks of the build in serial (

--max-workers 1

) with just barely enough memory and see during which task the daemon is running out of memory. We observed that this happens during large copy tasks. Is this expected to consume significant memory? Did anyone else also observe this? Any information is more than appreciated!

TL;DR How can I ensure that builds stay incremental (

UP-TO-DATE

) in a large monorepo (~50 devs)? I work in a monorepo with 50+ other engineers touching ~50-60 submodules. Developers will often add new modules or modify build logic for existing modules. It’s very easy for someone who is not familiar with Gradle to break the build’s incrementality. It’s not practical to expect everyone to be a gradle expert. At the same time, I want the build speed to be optimal. This seems like a great use-case for a CI or build check. My ideal solution would be for the Gradle build to fail if it finds that any task is not incremental (maybe with the ability to add an escape hatch for tasks which truly can’t be incremental). Does anyone have experience with implementing something like this? Any pointers would be super appreciated.

Is Gradle 8 supposed to be slower than 7.6? We have recently updated Gradle to 8.0.1 and observed 10% increase in compilation time for clean builds and > 25% increase for incremental builds.

I hope this is the right channel. In the gradle-profiler, is there a way to do a custom mutation? Let’s say I want a scenario on GraphQL Apollo code gen and compilation, I would need to introduce a mutation to one of the GraphQL schemas / queries file. I could not find anything in the doc allowing custom mutations.

Hello, why running tests from intellij/gradle is so slow ? I've couple of second of 'test instantiation' for a test taking 127ms to run ?

Hi all. In my builds tasks`Created during task graph calculation` is ~14500 but

All tasks

is ~8000. But according to configuration avoidance documentation, this number should ideally be same. Is there a way to debug why and which tasks are getting unnecessarily created?