can-i-drop-jetifier icon indicating copy to clipboard operation
can-i-drop-jetifier copied to clipboard

Plugin is too slow on large apps

Open stephanenicolas opened this issue 6 years ago • 3 comments

Hi @plnice , we have an app with 500+ libraries, 80 modules, and the plugin is too slow for us. After 30 minutes, it didn't complete.

It might be that you resolve configurations, I am not sure.

A workaround for us is:

./gradlew -Pandroid.enableJetifier=false :<app module>:dependencies --configuration <flavor><buildType>RuntimeClasspath | grep com.android.support

This command takes around 15 seconds to execute.

If you are interested, in one of our repo we use a very fast way to check dependencies: https://github.com/f2prateek/dart/blob/1c8d5e8863eb7b0b4595d6a6e8a8de150e0300f8/henson-plugin/src/main/java/dart/henson/plugin/internal/GenerateHensonNavigatorTask.java#L63

Maybe this would be the way for you to go as well. I am not sure. We would be happy to use the plugin if it could be run in 1-2 minutes on our nightly build.

stephanenicolas avatar Feb 14 '19 18:02 stephanenicolas

Hi @stephanenicolas, thanks for reporting the issue!

Indeed the problem could be resolving all configurations. I've just released a new version (0.3) that by default resolves only *RuntimeClasspath configurations, which should help a bit. Also, now you can control which configurations should be analyzed by specifying configurationRegex string in the plugin configuration.

Another optimization in 0.3 is checking only Android modules.

Please let me know if this solved your issue; if not, I will try the second way of checking dependencies you've provided.

plnice avatar Feb 16 '19 10:02 plnice

this time it completed in 30 min... So, no, the problem is not solved.

stephanenicolas avatar Feb 16 '19 15:02 stephanenicolas

OK. This indeed can be due to resolving configurations. Unfortunately, for now, I don't see a way to make the plugin work without resolving configurations due to the need of analyzing transitive dependencies. I have some plans on implementing my own lightweight mechanism for this, but it will take some time.

In the meantime, I've released v0.4. It includes some minor performance fixes and an experimental mode of analyzing modules in parallel. You can turn it on by specyfing parallelMode true option in the plugin configuration block. An optional parallelModePoolSize value specifies thread pool size (availableProcessors - 1 by default). Please let me know how this option affects your project and the analysis time.

plnice avatar Feb 24 '19 12:02 plnice