This message was deleted.

Depends on whether you talk about legacy script plugins (the ones you apply using "apply from") or precompiled script plugins. Legacy script plugins have many drawbacks and quirks. Precompiled script plugins effectively end up as binary plugins and can be tested the same as plugins written in Java / Groovy / Kotlin, ... and they look almost the same as build scripts and / or legacy script plugins just with much less of the quirks they have.

Yes im talking about precompiled script plugins vs binary plugin

Then I don't know why binary plugins should be any easier to test

im coming from android background, looking at the NowInAndroid repository, i found this interesting issue.

Well, I actually doubt that. This is probably depending on many factors and if those numbers come from a single run, it could as well be, that the computer was otherwise occupied and lost some time or similar. Both type of files need to be processed by the Kotlin compiler and both are not recompiled if there was no change. And even if you loose 10 seconds on compilation time, as long as those plugins are not changed, it is a one-time cost, so it might even then be worth to have more convenient syntax.

thank you for the discussion. I will measure my build with precompile script vs binary plugin and make a decision.

@Vampire looking at that Now in Android issue and PR, I don't think the time difference should be discounted. The PR does nothing other than replace precompiled script plugins with binary plugins, and if that causes such a drastic reduction in configuration and execution time it should warrant looking into. I'll test doing that in one of my projects and use the profiler to see what the difference is.

I didn't say they should be discounted @Eli Graber. I said I suspect the numbers might not be correct, for example if there was just one before and after run done, there could be many things influencing theses numbers and cause the additional 10 seconds like different network delay or computer being occupied with other tasks in the second run and so on. And I said that even if the numbers are correct, they are a year old and it might be different with todays versions and might drastically change again when K2 is ready. And i said even if the numbers actually are correct, they are just a one-time cost as long as the build logic does not change as the compilation is not re-done continually in either case and the execution time should imho not be different, so it might be an acceptable one-time time tradeoff for having nicer syntax to write. If you can reproduce resilient numbers by meaningful performance tests and can even tell whether it is due to Gradle code or due to Kotlin compiler code and can report it to the according project, that's great of course. 🙂

That's the plan 😁 It's also not a one time cost, because of clean builds, etc...

For a local developer? Noone should usually do clean builds. This is Gradle, not Maven. 😄

CI builds, repros, etc... It happens

Yes, of course, but 10 seconds might not be too bad for a CI build or a repro. Where every second counts - imho - is during the daily work of the poor developer soul. 🙂

I only got approx .5 seconds (5%) faster with Gradle 8.2.1 so maybe there's something else going on? My convention plugin included build is very small, so maybe it doesn't scale well?

Hi @Vampire, i got some profile report by running

./gradlew clean && ./gradlew app:assDebug --profile --offline --rerun-tasks

This is composite build on nowinandroid with 1 precompiled script plugin.

Benchmarks are like statistics. Never trust a statistic you didn't distort yourself. :-D Real benchmarks are hard to get right. You need to warm up, and repeat many times and so on. But as I said, the numbers seem to be meaningful, at least for that build. You also have a profiling report in

buildSrc/build

that shows that the major difference is within the

compileKotlin

task.