https://kotlinlang.org
Join Slack
are there ways to diagnose how long detekt checks take? When running detekt with type resolution, we...
# detekt
z
are there ways to diagnose how long detekt checks take? When running detekt with type resolution, we’ve been surprised to find it runs even slower than android lint (!!)
👀 1
e
I vaguely remember there being a profile somewhere. Although that may have actually been for android lint 🤔
g
Nope we don’t have benchmarks per rule. If you integrate with Gradle (I believe so), you can use all the usual profiling tools from Gradle but that will give you only a per-project metric.
we’ve been surprised to find it runs even slower than android lint (!!)
That sucks 😐 Is it consistently slower? The answer to those kind of problems is to use our compiler plugin as currently enabling TR effectively ends up costing as much as a new Kotlin compilation.
That being said, we can definitely expose some telemetry per rule imho
z
g
Yes. We’re actually moving it inside detekt/detekt so that will be published for every version from now on (so snapshots and so). I suspect in 1.23 will be pretty usable at this point.
b
I wrote about this some time ago here https://github.com/detekt/detekt/discussions/5183. But to be honest, I did nothing else about it.
z
What’s the plan for K2 support on that? I’m interested in better options, but as this appears to rely on AnalysisHandler I’d be curious what the longer term plan is
also - how does baseline generation work with the plugin?
g
Baseline generation: IIRC there is no such thing in the compiler plugin yet. The plugin is able to consume previously generated baselines.l though. We'll probably implement this as an extension field or a Gradle property of some sort
K2 support: it's something we should definitely look into. I'm planning to look into it over the Xmas break
b
I have some ideas on this direction: • We should split detekt in different tasksgradle tasks. • Task to check the configuration (this one should be nearly always up-to-date • Task to find all the issues and serialize them to a (internal) file. This one will never fail the build. • And another task to do the suppression and the reports (maybe two). This will allow us to show on the reports the suppressed issues and why they were suppressed. This will make that the only task related to the compiler is the second one. And, for example you could regenerate the baseline without running the checks again. And, if we have a serialized output with all the issues it should be way more easy to create merged reports.
z
for the compiler plugin - it looks like there is a lot of work on the main branch, but last release is 2020. Also last published release is 0.3.2, but I see a 0.3.3 on the gradle plugin portal. Could anyone shed any details?
the readme also appears to be out of sync with the release, as it mentions support that is on main but landed after the 2020 release
g
We just moved all the code inside detekt/detekt so whats on main will be shipped in the next RC of detekt. If you need a release of what we have so far, we can do a 0.4.0. I don't recall if someone published 0.3.3 without making a GH release. I can check what happened 👀
z
if it’s not too much trouble I’d be happy to test a 0.4.0, but fine with waiting too. Detekt’s just become a bit of a burning issue with how slow it is in the above scenarios 😅
g
I thought you folks were only using syntactic checks in pre commit hooks. How comes you enabled Type Resolution?
c
K2 support: it’s something we should definitely look into. I’m planning to look into it over the Xmas break
Early start: https://github.com/detekt/detekt/tree/k2
we’ve been surprised to find it runs even slower than android lint
Providing a datapoint for a large-scale Android app, lint runs for 10min for our codebase and detekt with type resolution runs for 6 min (we also run twitter-compose-rules) as well
are there ways to diagnose how long detekt checks take
If there is a buildscan to share it would be great, however it is a known issue that type resolution does redundant work of running compilation twice.
also - how does baseline generation work with the plugin?
My thoughts around baseline is that • When embarking adopting Detekt, baseline is super useful • When continuing upgrading Detekt, baseline often gets updated as the KtElement signature becomes implementation detail of Kotlin compiler and is very subjective to change. • In the longer term, I found annotation-based suppression is more useful and we can link to the Github issue in the code stating why a suppression is needed
Also adding folks to #k2-early-adopters channel 🤞
z
How comes you enabled Type Resolution?
Well, we’d like to run without blind spots basically. Many checks more or less don’t work in syntactic checks only (including ones that really matter to us), they’re quite noisy about the lack of type resolution, etc. If anything, I’m surprised that you’re surprised 😛. I figured the question would why not use type resolution?
here’s my own data point 🙃
If there is a buildscan to share it would be great
Unfortunately this is only really an issue in our internal repo 😕
> also - how does baseline generation work with the plugin?
I meant this question as a functional piece – the compiler plugin doesn’t have its own task, so how does it produce baseline files. Not intended as a philosophical one, sorry I was unclear.
c
Maybe the source of the 
:app:detektInternalDebugAndroidTest
has too many files? The Android codebase does not run detekt on non-main (e.g. test files), hence that might cut off the execution time. Although the counterargument could be that why test code does not have the same quality as production code.
z
we run on tests too. Never really understood why some think tests shouldn’t be beholden to static analysis. That project isn’t really that big either, which is why I think something else is sort of wrong here
c
Did you spot any high memory usage from lint? (I noticed that lint on the app module runs earlier)
Detekt with type resolution runs for 10 seconds in our app module 🤔
z
Hard to say from the build scans along, but detekt is significantly slower than lint analogues across the board and not just in later stages of the build
c
Could there be a long list of Detekt task's classpathes?
z
Possibly? But again, all areas of the build
All lint analysis tasks
Found 409 tasks executed in 409 projects totaling 1h 8m 45.581s
Detekt tasks
Found 750 tasks executed in 395 projects totaling 3h 34m 13.458s
these are the earliest detekt tasks
I think if memory was the issue, you’d be seeing the same effects on all tasks
memory more or less seems ok
actually - do you know if detekt uses the gradle daemon or kotlin daemon? I assume the former since it’s running in its own task
but if it’s somehow the latter, that could explain it
c
It should be the gradle daemon
We could also dump the exact detekt command to console by passing 
-Pdetekt-dry-run=true
z
Revisiting this another release on the radar still for the compiler plugin? Seems the README is out of date with the latest release too and it’s a hard sell to try it out in its current state
g
Sorry that’s my fault 🙏 I’ll get this sorted out hopefully tomorrow (we’ll probably publish 
0.4.0
from main + add a note on the readme + archive the repo). Next stable version will be 
1.23.0
Once I get it merged I’ll publish 0.4.0 on Central/Portal and archive it 👍 That should be closer to what we have on detekt/detekt
z
nice
g
Maven Central is having a hard day today/yesterday 😢 Will push it as soon as they’re back
68 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by