[native] performance issue with no-op-builds with boost as a dependency

Help/Discuss
1

Hi,

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?

Thanks!

2

You’re probably right. Thanks for noticing this and letting us know.

We just started work on optimizing up-to-date checks in the native plugins, so I’ll add this to our list of test cases. I think we naively add the prebuilt library’s headers as an input to the compile task, so we’ll scan the entire directory whether we need to or not.

One of our ideas was to “roll-up” checking up-to-date-ness to a higher level (than just the files), so we could share up-to-date checks across tasks.

Make sure you have the org.gradle.daemon and org.gradle.parallel options turned on too.

3

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.