I want to use

gradle-profiler

to profile some of my gradle tasks. Specifically I want to see how gradle configuration is affected by the

config-cache-parrellel=true

(since it is being enabled by default in 8.11). Is there a way to write a gradle profiler scenario for just running configuration? Should I just run the

help

task?

Probably

tasks

is better for such testing,

help

configures very little. If you want to focus on some specific task maybe using

--dry-run

can help too. Note: configuration-cache-parallel is not enabled by default

hmmm

I believe if your configuration is that fast it means also that configuration cache entry is pretty small and parallel store/load won't help much

Ive been now trying with

clear-configuration-cache-state-before

and it seems to make a difference. I can see now that configuration phase is about 7 seconds for my app while running help task. Running "tasks" task takes about 10 seconds. but I guess "help" task is closer to finding configuration time vs tasks task which might be "execution" time?

The only thing that runs at execution time for both

tasks

and

help

is printing the output to the console.

tasks

eagerly configures all tasks in the project, while

help

doesn't, so the former is slightly more representative. And, I think, neither is going to be particularly representative for the parallel CC, because Gradle shards storing the tasks per project. I.e. you need to have a multi-project build and tasks from many projects in the graph to see the difference.

Cool. That's all I needed to hear. My project doesn't fit that bill so I will stop with trying to benchmark the difference between config cache parallel flag on vs off. In general, if I wanted to benchmark my configuration time in between builds... would you recommend a scenario like this?

configuration {
  tasks = ["help"]
}

I got that from this article from tony R https://dev.to/autonomousapps/benchmarking-builds-with-gradle-profiler-oa8 Or (since i have config cache enabled already) would I need to run?

configuration {
  tasks = ["help"]
  clear-configuration-cache-state-before: BUILD
}

IMO, it depends on what you want to optimize. With cleaning you'll be testing a miss, without - a hit. I'd say optimizing misses gives more ROI, hit is already fast enough and there are fewer opportunities to optimize (though they definitely exist).