This is a simple tool to help pinpoint performance bottlenecks in individual Android Lint checks. It uses Java byte code instrumentation to collect and report performance statistics per detector for a Lint analysis invoked from Gradle. It relies on YourKit Probes to do the byte code instrumentation part, although in principle alternative instrumentation agents could be used.
This tool was involved in the 2x-level Lint performance improvements that landed with the Android Studio 3.3 release; there's a blog post with more details.
This tool requires a valid YourKit installation. YourKit is a paid profiler, although trial versions are available.
Once YourKit is installed, edit the properties in
gradle.properties to point to the corresponding files in your
YourKit installation. You will need to set both the
yourkitJar property and the
$ ./gradlew jvmArgs
to compile the tool and print out the JVM arguments needed to instrument Lint. Here's an example of what those JVM arguments will look like:
Add the generated arguments to your Gradle JVM arguments in an Android project. (See Gradle
for how to set the
org.gradle.jvmargs property.) Finally, invoke Lint from Gradle as you normally do. Once Lint
finishes, performance statistics for each Lint detector should be printed to the console. Here's some sample output:
$ ./gradlew lintDebug --no-daemon -Dorg.gradle.jvmargs="..." BUILD SUCCESSFUL in 10s 15 actionable tasks: 1 executed, 14 up-to-date Lint detector performance stats: total self calls LintDriver 3709 ms 1302 ms 2821 TopDownAnalyzerFacadeForJVM 2121 ms 2121 ms 6 IconDetector 81 ms 81 ms 257 OverdrawDetector 51 ms 51 ms 36 InvalidPackageDetector 34 ms 34 ms 51744 GradleDetector 20 ms 20 ms 94 LocaleFolderDetector 11 ms 11 ms 986 RestrictToDetector 11 ms 11 ms 19 ApiDetector 11 ms 11 ms 1255 PrivateResourceDetector 10 ms 10 ms 422 ...
Memory allocation instrumentation
The tool also supports measuring memory allocations through the use of an allocation instrumentation agent. To enable this, generate the JVM arguments with this command instead:
$ ./gradlew jvmArgs -Pallocations
Here's some sample output:
BUILD SUCCESSFUL in 22s 15 actionable tasks: 1 executed, 14 up-to-date Lint detector performance stats: total self calls LintDriver 1473 MB 589 MB 2821 TopDownAnalyzerFacadeForJVM 770 MB 770 MB 6 AppIndexingApiDetector 67 MB 67 MB 8 ApiDetector 13 MB 13 MB 1255 IconDetector 11 MB 11 MB 257 RestrictToDetector 8 MB 8 MB 19 PrivateResourceDetector 3 MB 3 MB 422 RtlDetector 2 MB 2 MB 10 GradleDetector 2 MB 2 MB 94 OverdrawDetector 1 MB 1 MB 36
If you get strange error messages from the Gradle JVM, double check that the JVM arguments are formatted and quoted properly. Quoting may be needed if there are spaces in the file paths, for example. Similarly, be aware that typos in the JVM arguments may cause YourKit to silently ignore the probe.
If the JVM arguments have been applied properly but you still don't see performance stats output, it's worth checking to see if YourKit has reported any errors---especially if you've made code changes to the probe. To do this, run
javawith the JVM arguments generated by this tool. YourKit should print a line to standard error like this.
[YourKit Java Profiler 2018.04-b88] Log file: /path/to/home/.yjp/log/java-191039.log
Open that log file to see if there were any errors reported. For example, if you added a malformed regular expression to the
LintDetectorStats.java, you might see a line like this.
Error: probe class com.android.tools.probes.LintDetectorStats$WrapDetectors: class name pattern is invalid: com.example.lint.checks..*Detector
Conversely, it's a good sign if you see a line like this.
If you make code changes to the tool, be sure to run
./gradlew assemblein order to rebuild the probe. Also, be sure to start a new Gradle daemon for Lint; otherwise the old version of the tool could still be in use. This is easy to do by using the
Notes and tips
The tool will print out three columns for each detector:
totalshows the total amount of time spent within any method in that detector
selfis similar to
total, but it excludes any time spent in other instrumented callees
callsshows the number of calls to any method in that detector
In addition to individual Lint detectors, the tool also instruments
LintDriverdrives the entire Lint analysis, so it will help show the total time spent in Lint.
TopDownAnalyzerFacadeForJVMis essentially the entry point into the Kotlin compiler, so it is a good proxy for how much time is spent upfront analyzing a Kotlin module before Lint detectors can start.
To include your own custom Lint checks in the output of the tool, you can add to the list of regular expressions in
Be aware that caching effects may distort the performance stats for individual detectors. For example, the first Lint check to run might get the blame for the initial cache misses when resolving calls, types, etc.