1

The feature build automatically under the eclipse is much faster than the ./gradlew build.

My findings after some research is that it compiles and builds only the changed file and replaces it in build folder.

So why can't ./gradlew build command compiles and builds files that have changed and replace it in build folder and make the whole building process faster.

I have recently started using build automatically feature with hotswap agent + DCEVM.

howlger
  • 31,050
  • 11
  • 59
  • 99
royatirek
  • 2,437
  • 2
  • 20
  • 34
  • 1
    Does `gradlew` use [Gradle 4.10 or higher](https://guides.gradle.org/performance/#incremental_compilation)? If not, [try to upgrade the Gradle wrapper](https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:upgrading_wrapper). – howlger Jan 04 '20 at 14:54
  • I use 2.7. I tried using 4.10 but surprising it took more time. 2.7 took nearly 40 seconds while 4.10 took more than a minute. Eclipse does all took things within 1 second. The reason maybe is that they don't go through configure step of gradle. Anyways I did not know that the gradle supports the incremental build feature. – royatirek Jan 04 '20 at 16:08
  • I would like to accept your answer if you write it. It will be bonus if you mention why gradle takes more time than eclipse build automatically. – royatirek Jan 04 '20 at 16:24
  • Was it only the first time slower when Gradle 4.10 was downloaded? The current Gradle version 6.0.1 should be even faster than Gradle 4.10. Eclipse knows which files have changed and perhaps the Gradle Eclipse plug-in Buildship uses this information to avoid time-consuming accessing of files to find out what has changed. – howlger Jan 04 '20 at 17:13
  • It took lot more time in first build with gradle 4.10. I am talking about subsequent builds. One more thing, is it safe to deploy the build after building with the build automatically feature of eclipse or we have to manually call ./gradlew build. I assume this eclipse feature is only good for hotswap and we should not take any chances. – royatirek Jan 04 '20 at 17:57

1 Answers1

2

Why can't gradlew build command compile and build only the things that have changed and make the process faster?

There's no dependable way how to determine what needs to be recompiled. For example, compile-time constants get inlined and there's no trace of where they come from in the class files (it can be found in the source files, that implies parsing them and losing time; it can be stored in some auxiliary files and some tools do it).

See the "Limitations" section of this for details.

The reason maybe is that they don't go through configure step of gradle.

Sure, but the configure step doesn't usually take that long.

Eclipse knows which files have changed

Good point (in a comment by holwgler).

Some time ago I spent some time trying to make my gradle compilation faster and I gave up. Eclipse is damn fast for many reasons:

  • incremental compilation
  • multithreading using all cores
  • knowing all changed files
  • having the whole compiler code optimized by the JIT
  • probably caching file dependencies
  • ugly highly optimized code

My "solution" is ignoring the problem. I do everything in Eclipse, except for integration tests (which take way longer than the compilation) and production builds (which are rare enough so I don't care).

You may want to read these performance tips.

To find out where the time gets spent, use

./gradlew clean; ./gradlew --profile jar

For me, 90% of the time is just :compileJava.

maaartinus
  • 44,714
  • 32
  • 161
  • 320
  • Can you try again without runing clean first? Without it, gradle does incremental compilation and it runs quite fast. – dblocks Feb 19 '20 at 21:23