# Tracing Gradle task execution

DevFeed: [Tracing Gradle task execution](<https://devfeed.tech/articles/tracing-gradle-task-execution-20979.md>)

Original publisher: [Read original article](<https://jakewharton.com/tracing-gradle-task-execution/>)

Published: 2018-08-01T00:00:00Z

Content type: article

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [tracing](<https://devfeed.tech/topics/tracing.md>), [ci](<https://devfeed.tech/topics/ci.md>), [Java](<https://devfeed.tech/topics/java.md>)

Tags: [analysis](<https://devfeed.tech/tags/analysis.md>), [build](<https://devfeed.tech/tags/build.md>), [ci](<https://devfeed.tech/tags/ci.md>), [concurrent](<https://devfeed.tech/tags/concurrent.md>), [flamegraph](<https://devfeed.tech/tags/flamegraph.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [jdk](<https://devfeed.tech/tags/jdk.md>), [performance](<https://devfeed.tech/tags/performance.md>), [performance-analysis](<https://devfeed.tech/tags/performance-analysis.md>), [profile](<https://devfeed.tech/tags/profile.md>), [tracing](<https://devfeed.tech/tags/tracing.md>)

## AI overview

This article explains ways to trace Gradle task execution and analyze build performance. It compares Gradle's built-in profiling and scanning mechanisms with local approaches using Gradle profiler integrations, Java Flight Recorder, Java Mission Control, command-line conversion, and flamegraphs, while noting limitations for CI builds and daemon-backed tasks.

## Source excerpt

Gradle provides two built-in mechanisms for tracing your build: --profile and --scan. The former produces a simple HTML report of task execution times. You can get a rough idea of where time was spent but are unlikely to glean any real insights. The latter sends a detailed report to Gradle's servers (or to a Gradle Enterprise installation) with much more granular information. Task details are rendered on a concurrent timeline corresponding to their execution. For CI builds, I tend to want something more granular than --profile but I don't like the idea of sending details of every build to Gradle with --scan. It seems entirely needless considering their plugin has all of that information locally but chooses to render it remotely. The Gradle profiler project started a few years ago as a way to deterministically measure build speeds. By creating scenarios such as an ABI-breaking change, ABI-compatible change, Android resource change, etc., the tool can run these scenarios multiple times to first warm up the JVM and then to produce an accurate picture of what gets executed. It offers integrations and outputs for use with popular JVM-based performance analysis tools such as YourKit and Java Flight Recorder. For CI builds, executing through the Gradle profiler would be an annoying abstraction to use. We can instead use it for inspiration and run its integrations on individual builds. Java Flight Recorder can be used on individual Gradle builds with the jcmd binary in the JDK and with flags to java specified on the org.gradle.jvmargs in your gradle.properties. There are even Gradle plugins which offer to start and stop the recording automatically. We can then open the resulting .jfr file in Java Mission Control or use a command-line tool to convert it into a flamegraph. The flamegraph can show where time is being spent inside of tasks over the course of the build. The stacks aren't correlated to a task, though, so it's important to remember that you're looking at the large