buildscript - gradle java application

¿Seguir el tiempo de ejecución por tarea en el script de Gradle? (5)

¿Cuál es la forma más elegante de rastrear los tiempos de ejecución en cuanto a la duración de una tarea en un script de compilación gradle? En un caso óptimo, registre el tiempo directamente en la misma línea o en la siguiente al nombre de la tarea

:buildSrc:testClasses (0.518 secs) :fooBar (28.652 secs)

Esta es una variación de la respuesta de jlevy anterior que se ha modificado para eliminar el uso de la clase de Clock gradle de acceso público, que ha quedado obsoleta.

BUILD SUCCESSFUL Total time: 1 mins 37.973 secs Task timings: 579ms :myproject-foo:clean 15184ms :myproject-bar:clean 2839ms :myproject-bar:compileJava 10157ms :myproject-bar:jar 456ms :myproject-foo:compileJava 391ms :myproject-foo:libs 101ms :myproject-foo:jar 316ms :myproject-bar:compileTestJava 364ms :myproject-foo:compileTestJava 53353ms :myproject-foo:test 2146ms :myproject-bar:test 8348ms :www/node:npmInstall 687ms :www/node:npmTest

Algo como el siguiente código se puede soltar en su build.gradle nivel build.gradle para informar los tiempos durante la ejecución, o después de la finalización.

import java.util.concurrent.TimeUnit // Log timings per task. class TimingsListener implements TaskExecutionListener, BuildListener { private long startTime private timings = [] @Override void beforeExecute(Task task) { startTime = System.nanoTime() } @Override void afterExecute(Task task, TaskState taskState) { def ms = TimeUnit.MILLISECONDS.convert(System.nanoTime() - startTime, TimeUnit.NANOSECONDS); timings.add([ms, task.path]) task.project.logger.warn "${task.path} took ${ms}ms" } @Override void buildFinished(BuildResult result) { println "Task timings:" for (timing in timings) { if (timing[0] >= 50) { printf "%7sms %s/n", timing } } } @Override void buildStarted(Gradle gradle) {} @Override void projectsEvaluated(Gradle gradle) {} @Override void projectsLoaded(Gradle gradle) {} @Override void settingsEvaluated(Settings settings) {} } gradle.addListener new TimingsListener()

La clasificación simple haría que la solución de @jlevy sea aún mejor.
Además, para las aplicaciones de producción típicas, creo que el umbral de 50 ms es demasiado bajo.
Por lo general, nos importan las tareas que tardan más de 1 segundo.
proyecto / build.gradle

import java.util.concurrent.TimeUnit // Log timings per task. class TimingsListener implements TaskExecutionListener, BuildListener { private long startTime private timings = [] @Override void beforeExecute(Task task) { startTime = System.nanoTime() } @Override void afterExecute(Task task, TaskState taskState) { def ms = TimeUnit.MILLISECONDS.convert(System.nanoTime() - startTime, TimeUnit.NANOSECONDS) timings.add(new Tuple2<Integer, String>(ms, task.path)) task.project.logger.warn "${task.path} took ${ms}ms" } @Override void buildFinished(BuildResult result) { println "Task timings:" def tmp = timings.toSorted(new Comparator<Tuple2<Integer, String>>() { @Override int compare(Tuple2<Integer, String> o, Tuple2<Integer, String> t1) { return o.first - t1.first } }) for (timing in tmp) { if (timing.first >= 1000) { printf "%ss %s/n", timing.first / 1000, timing.second } } } @Override void buildStarted(Gradle gradle) {} @Override void projectsEvaluated(Gradle gradle) {} @Override void projectsLoaded(Gradle gradle) {} @Override void settingsEvaluated(Settings settings) {} } gradle.addListener new TimingsListener()

Salida terminal:

BUILD SUCCESSFUL in 14m 33s 948 actionable tasks: 419 executed, 476 from cache, 53 up-to-date Task timings: 1.036s :cbl-config:mergeMyAppDebugResources 1.187s :express:bundleMyAppDebug 1.199s :country:testMyAppDebugUnitTest 1.214s :core-for-test:extractMyAppDebugAnnotations 1.242s :analytics:testMyAppDebugUnitTest 1.308s :express:extractMyAppDebugAnnotations 1.33s :availability:dataBindingExportBuildInfoMyAppDebug 1.357s :app:transformNativeLibsWithStripDebugSymbolForMyAppDebug 1.405s :hermes:generateMyAppDebugBuildConfig 1.56s :availability:testMyAppDebugUnitTest 1.65s :app:javaPreCompileMyAppDebugUnitTest 1.749s :chat:compileMyAppDebugJavaWithJavac 1.858s :cbl-config-for-test:compileMyAppDebugJavaWithJavac 2.027s :cbl-config:compileMyAppDebugJavaWithJavac 2.056s :analytics-for-test:compileMyAppDebugJavaWithJavac 2.447s :crypto:compileMyAppDebugJavaWithJavac 2.45s :crypto:testMyAppDebugUnitTest 2.47s :chat:javaPreCompileMyAppDebugUnitTest 2.639s :crypto-for-test:dataBindingExportBuildInfoMyAppDebug 2.683s :test-utils:compileMyAppDebugJavaWithJavac 3.056s :crypto:lintMyAppDebug 3.227s :app:transformNativeLibsWithMergeJniLibsForMyAppDebug 3.272s :express:testMyAppDebugUnitTest 3.394s :crypto:mergeMyAppDebugResources 3.426s :core:testMyAppDebugUnitTest 4.299s :multicity:testMyAppDebugUnitTest 4.333s :app:packageMyAppDebug 4.584s :availability-for-test:compileMyAppDebugJavaWithJavac 4.672s :app:transformResourcesWithMergeJavaResForMyAppDebug 4.786s :map:lintMyAppDebug 5.309s :country:lintMyAppDebug 5.332s :job:lintMyAppDebug 5.389s :map:testMyAppDebugUnitTest 6.04s :express:lintMyAppDebug 6.584s :hermes:lintMyAppDebug 6.707s :app:transformClassesWithMultidexlistForMyAppDebug 7.052s :multicity:lintMyAppDebug 8.044s :multicity:compileMyAppDebugJavaWithJavac 8.87s :app:transformDexArchiveWithDexMergerForMyAppDebug 9.371s :uikit:testMyAppDebugUnitTest 9.429s :availability:lintMyAppDebug 13.12s :app:compileMyAppDebugUnitTestKotlin 16.276s :hermes:testMyAppDebugUnitTest 16.898s :chat:testMyAppDebugUnitTest 17.174s :job:testMyAppDebugUnitTest 36.008s :grab-junior:testMyAppDebugUnitTest 96.88s :app:compileMyAppDebugJavaWithJavac 125.693s :app:lintMyAppDebug 145.538s :app:transformClassesWithDexBuilderForMyAppDebug 182.752s :app:testMyAppDebugUnitTest

La solución más limpia es implementar TaskExecutionListener (estoy seguro de que puede manejar esa parte) y registrarla con gradle.taskGraph.addTaskExecutionListener .

Sé que esta es una vieja pregunta, pero he encontrado un complemento genial que hace el tiempo de la tarea. Es como @jlevy answer, pero con algunas opciones más disponibles: https://github.com/passy/build-time-tracker-plugin

Este complemento de Pascal Hartig registra continuamente los tiempos de compilación y proporciona resúmenes de gráficos CSV y de barras. El desarrollador lo recomienda para monitorear los tiempos de compilación a lo largo del tiempo, en comparación con --profile que proporciona una instantánea de la compilación actual.

Así es como lo estoy usando actualmente:

buildscript { repositories { mavenCentral() } dependencies { classpath "net.rdrei.android.buildtimetracker:gradle-plugin:0.7.+" } } apply plugin: "build-time-tracker" buildtimetracker { reporters { summary { ordered false threshold 50 barstyle ''unicode'' } } }

Solo para explicar la otra respuesta: queríamos hacer lo mismo, así como los tiempos de informe al final de la compilación, por lo que los pasos lentos son obvios (y las partes apropiadas sienten una pequeña pero saludable vergüenza cuando reducen la velocidad ¡La construcción!).

Algo como el siguiente código se puede soltar en su build.gradle nivel build.gradle para informar los tiempos durante la ejecución, o después de la finalización.

// Log timings per task. class TimingsListener implements TaskExecutionListener, BuildListener { private Clock clock private timings = [] @Override void beforeExecute(Task task) { clock = new org.gradle.util.Clock() } @Override void afterExecute(Task task, TaskState taskState) { def ms = clock.timeInMs timings.add([ms, task.path]) task.project.logger.warn "${task.path} took ${ms}ms" } @Override void buildFinished(BuildResult result) { println "Task timings:" for (timing in timings) { if (timing[0] >= 50) { printf "%7sms %s/n", timing } } } @Override void buildStarted(Gradle gradle) {} @Override void projectsEvaluated(Gradle gradle) {} @Override void projectsLoaded(Gradle gradle) {} @Override void settingsEvaluated(Settings settings) {} } gradle.addListener new TimingsListener()