I’ve been playing around with hooking in Gradle’s listeners to write out build information in Chromium’s Trace Event Format, as a way to investigate build performance. So far, the results look pretty promising, though there’s still a lot left to do. Here’s a sample from running gradlew quickCheck on the Gradle project, with parallel turned on - you can see how there’s a period o f time where everything’s waiting on :core:compileJava, for instance.
I’m hoping to get this to take advantage of flow events so I can get arrows showing relationship of which tasks are blocking which, but… we’ll see.
Just thought I’d share, in case anyone found it interesting.
I really like this!
Although things might be available in build scans, not all of us will be able use them in a corporate environment (not even Enterprise).
So anything that enables better tracing/debugging of task is always welcome. Especially if it could at some point become incorporated into core.
Have you made a plugin for it?
Oh, that is cool! Is that new? It’s been a little while since I played with build scans but I didn’t see that before. That’s way easier than my homegrown one.
Are you aware of the Gradle Profiler? It has supported chrome traces for a while now. It warms up your build before creating these traces in order to get reliable results. The traces it creates also contain memory and CPU usage, garbage collector activity and a rich set of events.
It also supports build scan creation, YourKit, JProfiler and Honest Profiler. It’s the perfect companion for build scans, especially for lower-level optimizations.
Here is an example trace created for an up-to-date 500-project build:
I have not - honestly it’s just done right now as an init script you pass with -i. But I can throw it in a GitHub Gist once I clean it up a bit and toss it your way.
Nope, I had not seen that. Will definitely try it. Sometimes it’s hard to keep up with new plugins if they aren’t announced on the blog or newsletter.
Is this a candidate for inclusion into the main distribution at some point?
@rhencke I guess gradle-profiler will replace the need for a gist Thanks for sharing though, since it enabled me to find this.
Thanks for sharing though, since it enabled me to find this.