-
Notifications
You must be signed in to change notification settings - Fork 164
release 4.23.4 of the build-info-extractor-gradle plugin is slow and uses a lot of memory #487
Copy link
Copy link
Closed
Labels
bugCreate a report to help us improveCreate a report to help us improve
Description
Describe the bug
We use Gradle 5.6.4 with the build-info-extractor-gradle and gradle-dependency-lock. The latest release (4.23.4) seems to have massively increased the memory usage and resolves dependencies much slower.
- The build is much slower. Taking thread dumps of the Gradle daemon reveals this as a culprit:
at java.lang.RuntimeException.<init>(RuntimeException.java:62)
at groovy.lang.GroovyRuntimeException.<init>(GroovyRuntimeException.java:37)
at groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:1749)
at groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:1556)
at org.codehaus.groovy.runtime.InvokerHelper.invokeConstructorOf(InvokerHelper.java:1042)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.asType(DefaultGroovyMethods.java:11672)
at org.codehaus.groovy.runtime.dgm$55.doMethodInvoke(Unknown Source)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1217)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1041)
at org.codehaus.groovy.runtime.InvokerHelper.invokePojoMethod(InvokerHelper.java:999)
at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:990)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:182)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.asType(ScriptBytecodeAdapter.java:605)
at org.jfrog.gradle.plugin.artifactory.extractor.listener.ArtifactoryDependencyResolutionListener.updateDependencyMap(ArtifactoryDependencyResolutionListener.groovy:64)
i.e. using 'as String[]' on a List seems to be a Grovvy performance trap.
- memory usage, our Gradle daemon started to run out of memory.
With latest version:

In comparison 4.21.0:

Both while running 'gradle generateLock'.
Versions
- Extractor version: bad: 4.23.4, good: 4.21.0
- Operating system:
- Artifactory Version:
Additional context
A quick inspection of a heap dump seems to indicate massive duplication of version strings. Using G1 collector and -XX:+UseStringDeduplication helps a bit with the heap usage.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugCreate a report to help us improveCreate a report to help us improve