Colton Idle
10/07/2025, 8:07 PMprintln() and rebuild.
If I do this like 10 times in a row manually I get about a ~4 second build time. If I use gradle profiler with apply-non-abi-change-to ("Change the body of a public method in a Java or Kotlin source class.") the lowest time I'll see is a 7 second build time over the 10 default runs (with default 6 warm ups).
Anyone have a clue on how to debug why it seems like like build time is consistently close to twice of what "real world" testing shows?Andrey Mishchenko
10/08/2025, 4:02 AMAndrey Mishchenko
10/08/2025, 4:03 AMAndrey Mishchenko
10/08/2025, 4:03 AMColton Idle
10/08/2025, 1:43 PMAndrey Mishchenko
10/08/2025, 2:37 PMAndrey Mishchenko
10/08/2025, 2:38 PMit should use my gradle properties in both situations so it should be using the daemonIt's just an example about daemon, profiler can override pretty much everything, including JVM
Colton Idle
10/08/2025, 3:41 PMAndrey Mishchenko
10/09/2025, 1:16 AM--profile buildscan. The build scan URL is reported on the console and is also available in profile-out/profile.log.
https://github.com/gradle/gradle-profiler?tab=readme-ov-file#gradle-build-scansAndrey Mishchenko
10/09/2025, 1:19 AM"Change the body of a public method in a Java or Kotlin source class."
Because if different file is changed or change is different (like accidentally change inline function for example), your build time also could be different
Not that it's the most possible reason for it, but just one more conciderationColton Idle
10/11/2025, 12:38 PM