This message was deleted.
# community-support
s
This message was deleted.
✔️ 1
t
From the Kotlin DSL API doc,
withType<…> { … }
is equivalent to `withType<…>().all { … }`: https://docs.gradle.org/current/kotlin-dsl/gradle/org.gradle.kotlin.dsl/with-type.html, exactly like Java's
withType(class, action)
(https://docs.gradle.org/current/javadoc/org/gradle/api/DomainObjectCollection.html#withType-java.lang.Class-org.gradle.api.Action-)
s
Ok, but then does the
.all { ... }
behave like
.configureEach { ... }
? I tried to find the corresponding source code but did not succeed.
I'm trying to understand if there is any performance concern using one vs the other, because I recently saw multiple reviews going from the short kotlin extension to the
configureEach
for no obvious reasons 🤔
t
No
.all { … }
eagerly realizes all tasks, whereas
.configureEach { … }
will only configure the task when they are realized by other means (most likely because they need to be executed, that should be the goal).
.configureEach { … }
was specifically added for task configuration avoidance.
From the page you linked above:
Instead of:
DomainObjectCollection.all(org.gradle.api.Action)
Use:
DomainObjectCollection.configureEach(org.gradle.api.Action)
tl;dr: use
tasks.withType<…>().configureEach { … }
, and avoid
tasks.withType<…> { … }
(or the equivalent
tasks.withType<…>().all { … }
)
s
Thanks a lot for this!
If only these methods could have been flagged as "deprecated", "dangerous" or something similar. :)
💯 1
v
Well, the problem is, they are not. Most containers are not treated lazily but all elements are realized anyway. For those it does not really matter which one you use, so there is no real reason to mark them as deprecated - which would even mean they get removed - or dangerous. The main collection where it is relevant currently is the task container. It doesn't hurt though to always use the lazy variants either. 🙂
s
It makes sense, thanks for clarifying. Then, would it have been possible to flag the overriden methods on the TaskContainer class instead? Or maybe an easier way to surface these eager calls on the build scan? I feel like they are a bit hidden, even though they negatively affect the overall build.
v
On the build scan it is pretty obvious actually. 🙂 If you go to "Performance -> Configuration", you see "Created during configuration" and "Not created". If you use something eager like
tasks.all { }
or
tasks.withType<...> { }
you have no "Not created" tasks and many "Created during configuration" tasks. The "Created during configuration" ones should be near to zero usually.
s
Yes, it is obvious when you know where to look at 🙂 I was thinking about warnings in the main/root page.
v
Feel free to post a feature request to the Gradle folks for that if there is none yet. 🙂 At least there is some issue for some mode that warns when using things like eager methods instead of lazy methods iirc, but I don't find it right now.
👍 1