Background:- C++ Swerve Drive using SwerveDrivePoseEstimater for odometry (included this detail because I read somewhere that this could contribute to large build times)
We need help to reduce our c++ build times. Currently sitting at 15 minutes+ and this killed us at a recent competition. We had a couple of bugs in our auto routines and just didn’t have enough time to build, push and test code.
I’ve searched Chief Delphi and found a few thing things that might help reduce this time but I wanted to get the opinions of the CD community before we attack our code.
This is our first year on C++ and a complete new set of coding students, so each commands and command groups were written long hand. IE A separate file and class definition for every command and command group. That gave us a total of 83 headers and 83 cpp’s in the project. Am I correct in assuming this is a major cause of our large build times. I saw one thread that said each file contributes ~3 second to the total time, so this could explain 166 x 3 sec = 8.3 minutes.
I also read that choosing deploy rather than build will half the times as the debug exe isn’t compiled/linked when deploying. (wishing we had found this one before the competition)
I also read that choosing some offline option in gradle will also help build times.
So my questions are
Do we to need to move away from the one file for each command approach to a one line approach where commands are defined as lambda in the button binding?
Should we also build our command groups in the button bindings in that one liner style?
How do we modify gradle permanently so that is doesn’t build a debug exe as we are not using the debug feature?
What file do we modify to add the “offline” option to gradle that apparently helps build times?
There was also something about desktop support, how do we check/ modify this setting to reduce build times?
Order what should be prioritised specification wise if we were to purchase a new laptop to help with build times?
CPU type, speed, cores
GPU (I don’t think this has anything to do with build times, but I thought i ask the question just in case)
Hard Drive type eg SSD
Getting corporate Antivirus setting changed to exclude source folders for FRC projects.
Thanks in advance for any recommendations given.
If you open a terminal in your project and run ./gradlew build --scan it will give you a link to view a detailed record of everything that happened during your build. This could help you track down if there is some specific part of the build process that is leading to your long build times. Make sure you are connected to the internet when you run this.
Do you happen to know what model laptop you are currently using?
Our team has been using C++ for the longest time and I have been seeing this issue, although it isn’t necessarily 15+ minutes to build, it was still longer than usual. If you have the opportunity to use another laptop, I will highly recommend this. Also, I would look into what you are printing to your SmartDashboard and RoboRio Log, then see what you need and don’t need, then comment what you don’t need. I would start there then see how long your load time is
Yes, with modern command-based, you shouldn’t really have a file per command. Fewer files = less compilation time.
“Include-what-you-use” practices are important–you shouldn’t be including things you aren’t using, e.g. don’t have one .h file which has a bunch of expensive things in it that gets included everywhere. For things you have to include in a bunch of places, there are various techniques (e.g. pImpl) for minimizing what those headers include.
Desktop support can be disabled either when creating the project or via the WPILib menu in vscode.
Specs wise, SSD, the more CPU cores the better; note you should plan on 1-2 GB of RAM per core for the compiler alone (plus 2-4 GB for base OS/other programs).
How long does it take you to build the SwerveDrivePoseEstimator example? That can help you compare how much additional time your other code is adding.
For reference, my 4 core laptop that’s 3 years old built it in 4 minutes with desktop support enabled. The next build took 2 minutes. My 8 core desktop that’s 6 months old built it in 1.5 minutes. It did use all 8 cores (16 threads) while building. Here’s the build scan from my laptop: Build Scan™ | Gradle Cloud Services
Command references for below answers
If you post a link to your code, people may be able to give more concrete suggestions. For example, one thing that rookie programmers sometimes do is add more includes that are needed which increases build times. You could use a tool like https://include-what-you-use.org/ to help find those instances.
I wouldn’t really expect this to make that much of a savings
WPILib: Change Run Commands Except Deploy/Debug in Offline Mode Setting - Change whether GradleRIO is running in Online Mode for commands other then deploy/debug (will attempt to automatically pull dependencies from online). Defaults to enabled (online mode).
WPILib: Change Desktop Support Enabled Setting - Change whether building robot code on Desktop is enabled. Enable this for test and simulation purposes. This defaults to Desktop Support off.
SSD is a must. Antivirus is definitely something that can interfere. GPU is not important. I’d look for 16 gb or ram and the fastest CPU with the most cores you can afford.
You may want to look at this thread from 2 years ago: How to get VSCode to only build release and not debug - #34 by chauser
I don’t know how much gradle has advanced in the last two years, but there were definitely bad ways to structure a project back then that could cause gradle to recompile everything when one would think that only a single file should need to be compiled.
Ultimately, I figured out how to use ccache (https://ccache.dev/) along with gradle on both Windows and Linux and made some scripts to reconfigure machines to take advantage of it. They are out of date now, but if you want to try to resurrect them you can find them on Bitbucket
In 2021 we switched to Java and have been enjoying builds that take 5 seconds – we try out a lot more ideas in actual code now!