search

spring-gradle-plugins / dependency-management-plugin

A Gradle plugin that provides Maven-like dependency management functionality
690 stars 88 forks source link

Applying Spring Boot Gradle plugin to large scale multi project slow down IntelliJ reload. #288

Closed kazuki-ma closed 3 years ago

kazuki-ma commented 3 years ago

Enhancement (please don't include this emoji/text, just add your details)

(Moved from https://github.com/spring-projects/spring-boot/issues/24612)

Problems

We have large scale server side project using spring-boot gradle plugin. (~200 modules)

After using spring-boot dependency management, IntelliJ idea gradle reload tooks over 2 minutes. If I set setApplyMavenExclusions(false) it reduced to 30 seconds. (improved. But I thinks it's not best).

Goal

If you have any idea (Known limitation, option or workaround etc..) please let me know.

kazuki-ma commented 3 years ago

In my case, if setApplyMavenExclusions(false) is set isDependencyOnLocalProject is one hotspot.

image

kazuki-ma commented 3 years ago

In my caseisDependencyOnLocalProject occupied 12,540 samples by profiler (25,460 samples total). It's about 50% of CPU usage.

Graphs below. Full width = all java code execution during IntelliJ reload. Except GC time. Highlighted width = isDependencyOnLocalProject execution.

image

This is because gradle's .getAllprojects() is heavy and not optimized for frequency call.

This hotspot executes every (project x configuration x dependency pair) 😢 .

Anyway, in this use case, we can cache local project name.

kazuki-ma commented 3 years ago

Another reason of why gradle realod is heavy is applyMavenExclusions.

image

Note: There is workaround. put setApplyMavenExclusions(false).

There are any significant difference in my case. (example: protobuf module is exclude from MySQL connector or not)

wilkinsona commented 3 years ago

Thanks for the report. The support for Maven-style exclusions has been through a few rounds of optimisation and I think it's as fast as it can reasonably be. Caching the local project names sounds like a good thing to do. We can use #289 to do that (thanks for the PR).