Performance problems

Performance problems

Why is my build stuck?

Is it stuck with DependencyCheck?

• Make sure you are using 10.0.0 or newer of the Gradle or Maven plugin.
• Are you using an NVD API key to access the CVE data?
• Is the NVD REST API timing out? Sometimes the site gets overloaded.

Why is my local build slow?

Both Gradle and Maven have tools to track performance time of steps in your build:

• Gradle build scans — Not limited to Enterprise licenses, just build with ./gradlew --scan <tasks> and follow the link in the output.
  • Example
• Maven profiler — run with ./mvnw -Dprofile <goals> and open the local link in the output. This project includes the setup for Maven extensions.
  • HTML example
  • JSON example
  • Console example

Important

For Gradle reports, you are prompted for a valid email address to receive the report link from a hosted site.

My local build is still too slow

Congratulations! 🎉
You care, and you notice what is happening to you and your team.

Local build time is important: gone are the days when a multi-hour, or even a 30+ minute build are viewed in most cases as the "cost of doing business". And "compiling" or "pulling dependencies" now sounds lame.

Note

Are you always running a "clean" build from scratch after pulling changes, or after your own changes? This is a smell: your build system is letting you down: Fix your build to speed you up, speed up others, and speed up your pipeline. All modern languages (not just JVM languages) have tools to help you.

If you're smug, and say "my build doesn't recompile or recheck past builds", then pat yourself on the back: your next project may not be so fortunate.

Use the Gradle or Maven instructions in keep your build fast to profile your build, and spot where it spends time.

If you find your local build is taking too long, consider testing moving these parts to CI with the cost to you of issues arising from delayed feedback:

• Jdeps
• DependencyCheck
• Integration tests
• PITest

But beware! Your local build is now drifting away from CI, so you are pushing problems off later in your build pipeline. Not everyone pays close attention to CI failures, that is until something bad happens in production.

Important

If you disable tools like the above in the local build, ensure you retain them in your CI build. Your goal in this case is speed up the feedback cycle locally while retaining the benefits of automated tooling. You are making a bet: Problems these tools find come up rarely (but can be catastrophic when they do so), so time saved locally repays time lost waiting for CI to find these problems. Judge and measure your bets and decide if the payoff works for you.

In the Gradle and Maven samples in this repository, DependencyCheck and Mutation testing are typically the slowest steps in a local build; Integration tests are fast only because this project has very few (1), and are samples only. YMMV

Every project is different; your team and stakeholders need to judge the value of quicker feedback to programmers of these concerns, and quicker feedback from a faster local build. There is no "one size fits all" recommendation.