our Gradle build takes around 2 minutes and 20 seconds for a no op build. I’ve used the --profile option to pin down the problem and I found out that the compile tasks for those components that depend on the boost library as a prebuiltLibrary (api only) take around 3 to 3.5 seconds each. The boost library consists of more than 10,000 header files and I suspect that’s the source of the problem. Am I right to assume that Gradle checks all those files for changes? And does Gradle do so for each component separately? If so, is there a way to prevent Gradle from checking prebuiltLibraries for changes? We’re not editing 3rd party libraries like boost. Once in a while we’re updating to a new version, but that’s it. I think there is no need to check for changes in each build.
If my assumptions were wrong, does anybody have another explanation for our performance issue or can help me find the right one?
Is it possible to set a filter (include/exclude) for this like in the component source sets? I could then set a filter to an imaginary file type and have Gradle ignore all those *.hpp files as a temporary work-around. On second thought that would probably not be of much help, because Gradle would still have to scan all those folders and iterate over the files to apply the filter. The only way this would help is if it was possible to prevent Gradle from recursively scanning the sub folders. (*.x vs. **/*.x)
I think that would be a major improvement, not just for prebuilt libraries.
I’m using the daemon, but I’ll also look into the parallel option.
And of course, it’s not really about the no op builds, that’s just where the performance issue is most apparent.