oss-review-toolkit / ort

A suite of tools to automate software compliance checks.
https://oss-review-toolkit.org
Apache License 2.0
1.59k stars 309 forks source link

Low Speed of gradle dependency analyze #2302

Closed dd-jy closed 3 years ago

dd-jy commented 4 years ago

Hi, I tested the analyzer module for the various package managers. And then I wonder that the performance of analyzer module for gradle is actually low compared to other package mangers (npm, pip, maven).

Can you explain it to me? Thank you!

sschuberth commented 4 years ago

That's probably because of https://github.com/heremaps/oss-review-toolkit/issues/2115, although that affects Maven projects, too.

For NPM projects we basically have the same issue, and there it's even worse, as there is no NPM command to only determine the dependencies without actually installing them.

dd-jy commented 4 years ago

Actually, it's too low even if it takes time to install the jars. I used the gradle license plugin(https://github.com/hierynomus/license-gradle-plugin) previously. I tested the same java project with the ORT and gradle license plugin. The plugin only took 6 sec for downloading license information.

On the other hand, npm runtime is acceptable compared to license-checker(https://github.com/davglass/license-checker) even though it includes installation time.

I hope this information is helpful. Thank you for your help! It's really helpful to me :).

sschuberth commented 4 years ago

Actually, it's too low even if it takes time to install the jars.

Well, I'd say that depends on the time need to download the JARs :wink:

But I cannot rule out that there are additional factors that influence performance. So let's keep this open until #2115 is fixed and you can confirm the performance to be somewhat on par with the license-gradle-plugin.

sschuberth commented 3 years ago

Issue #2115 was fixed meanwhile, and additionally I just merged https://github.com/oss-review-toolkit/ort/pull/3502, which in sum should greatly improve Gradle project analysis thanks to @oheger-bosch's work.