Performance problem during migration from 6.0.3 to 6.2.2

[kezhevatov]

Have a problem during migration from 6.0.3 to 6.2.2 in Spring Boot application.
Obfuscation time is 4-5 times slowly at the same project.
Main reason is -keep class params in proguard.conf.

Build time minimal project with params (Java 8, Spring Boot 2.3.3, ProGuard 6.0.3 and 6.2.2):
all clases are absent in project

`
-verbose
-ignorewarnings
-dontshrink
-dontoptimize
-useuniqueclassmembernames

-keep class !com.example.demo1.v.,!com.example.demo1.a.,!com.example.demo1.b.** { *; }
-keep class !com.example.demo1.c.,!com.example.demo1.d.,!com.example.demo1.i.** { *; }
-keep class !com.example.demo1.e.,!com.example.demo1.f.,!com.example.demo1.j.** { *; }
-keep class !com.example.demo1.h.,!com.example.demo1.l.,!com.example.demo1.m.** { *; }
-keep class !com.example.demo1.dd.ff.,!com.example.demo1.ee.gg. { *; }
-keep class !com.example.demo1.zz.cc.,!com.example.demo1.xx.,!com.example.demo1.fft.t.** { *; }
-keep class !com.example.demo1.ww.,!com.example.demo1.tte.,!com.example.demo1.oop.** { *; }
-keep class !com.example.demo2.e.,!com.example.demo2.f.,!com.example.demo2.j.** { *; }
-keep class !com.example.demo2.h.,!com.example.demo2.l.,!com.example.demo2.m.** { *; }
-keep class !com.example.demo2.dd.ff.,!com.example.demo2.ee.gg. { *; }
-keep class !com.example.demo2.zz.cc.,!com.example.demo2.xx.,!com.example.demo2.fft.t.** { *; }
-keep class !com.example.demo2.ww.,!com.example.demo2.tte.,!com.example.demo2.oop.** { *; }
`
are

6.0.3 -> 5 seconds
6.2.2 -> 20 seconds

without -keep class:

6.0.3 -> 3 seconds
6.2.2 -> 4 seconds

Example of minimal spring boot application with these params:
https://github.com/kezhevatov/proguardPerformanceProblem

[mrjameshamilton]

Hi @kezhevatov ! Thanks for the detailed report and sample! I tried the sample and confirmed your findings. I also tried with 7.0.1 and the problem seems to have been fixed. Can you confirm if 7.0.1 fixes the problem for you?

[adamhamlin]

Fyi I see this issue as well. Any idea when 7.0.1 will be up on https://mvnrepository.com/artifact/net.sf.proguard/proguard-base?

[mrjameshamilton]

Hi @adamhamlin! Do you see this with 7.0.1 also? Or only 6.2.2?

Regarding the availabilityof 7.0.1: as of 7.0.0 the group ID is now com.guardsquare and it's available on JCenter already - https://mvnrepository.com/artifact/com.guardsquare/proguard-base (For Maven Central: keep an eye on this issue #54)

[adamhamlin]

Ahh, thanks for the info @mrjameshamilton. I was able to grab 7.0.1 from JCenter.

Using 7.x helped, but there still seems to be a performance issue. For your awareness, here are the metrics when running against our "standard" build task:

Proguard version	Time to obfuscate
6.0.3	8 min
6.2.2	64 min
7.0.1	32 min

It's interesting those numbers are such clean multiples of one another (I didn't fudge them; they're all +/- 5 sec)

[mrjameshamilton]

Interesting numbers @adamhamlin! Do you have a reproducible sample?

[adamhamlin]

@mrjameshamilton unfortunately the task I'm using is all private/company code, but I can tell you that we have a multi-module maven project (which is a Spark application), ~300 non-test files, and we use the proguard-maven-plugin.

The error I was getting with 6.0.3 was just for some Java 11 classes in META-INF/versions, but those aren't needed/I can just filter them and stick with 6.0.3.

[samoylenkodmitry]

@mrjameshamilton unfortunately the task I'm using is all private/company code, but I can tell you that we have a multi-module maven project (which is a Spark application), ~300 non-test files, and we use the proguard-maven-plugin.

The error I was getting with 6.0.3 was just for some Java 11 classes in META-INF/versions, but those aren't needed/I can just filter them and stick with 6.0.3.

@adamhamlin hi, this is unrelated to the topic, but what was your problem with META-INF and how you solved it?

[adamhamlin]

@mrjameshamilton unfortunately the task I'm using is all private/company code, but I can tell you that we have a multi-module maven project (which is a Spark application), ~300 non-test files, and we use the proguard-maven-plugin.
The error I was getting with 6.0.3 was just for some Java 11 classes in META-INF/versions, but those aren't needed/I can just filter them and stick with 6.0.3.

@adamhamlin hi, this is unrelated to the topic, but what was your problem with META-INF and how you solved it?

Our code uses multi-versioned dependencies (specifically, Java 8 and Java 11), and so the Java 11 classes would live in META-INF/versions. Proguard 6.0.3 can't process Java 11 classes, so it would error. But we don't actually use Java 11 in our builds, so it's fine to ignore them.

We ignored them by adding the following to the proguard-maven-plugin <configuration>:

<inLibsFilter>!META-INF/versions/**</inLibsFilter>

[samoylenkodmitry]

@adamhamlin I have the same problem but we use gradle instead of maven and there is no simple way to exclude it...

[mrjameshamilton]

HI @samoylenkodmitry ,

If you're using the Gradle ProGuardTask you can filter the injars like this:

task ('proguard', type: ProGuardTask) {
    injars 'my.jar', filter: '!META-INF/versions/**'
}

If you're using a ProGuard configuration file, you can filter like this:

-injars my.jar(!META-INF/versions/**)

This kind of question is perfect for asking on the Guardsquare community. If you have further questions like this, head over there where you can get tips and advice on your configuration from our team of engineers and skilled community members.

[samoylenkodmitry]

@mrjameshamilton thank you! Unfortunately I can't apply this solution. Now I asked a question here https://community.guardsquare.com/t/cant-compile-android-jackson-duplicate-module-info-class/596