Improving build times with Google Mock
Asked Answered
L

0

6

I'm looking for strategies to improve my build times with googletest and am wondering if what I'm seeing is typical, if there's a particular feature that can be avoided to improve build times, or if I'm just doing something wrong.

I have seen this post but its about 2 years old now.

I've been profiling with a moderately simple test fixture that has 24 tests and uses the following googlemock features. I apologize for not being able to provide a complete example here, but obviously for trivial examples, the build times are negligible. If you have experience on this topic and have a hunch, I can certainly fill in more details upon request. In total, the build is about 37 files including the googletest sources.

using ::testing::_;
using ::testing::AnyNumber;
using ::testing::DoAll;
using ::testing::Exactly;
using ::testing::InSequence;
using ::testing::Mock;
using ::testing::NiceMock;
using ::testing::Return;
using ::testing::SetArgReferee;

I've built my example with both clang 3.7.0 and mingw64-g++ 5.3.0 using cmake and ninja. See the times below. A full build is time required for all sources in project, including googletest. The compile+link is time required to build the single test fixture source and link. And link is time to create test executable. I tried the tuple flag, but as you can see, that didn't make much difference.

With the times as they are, they present some challenges for keeping the fix/build/test cycle snappy. It was interesting to me that configuration made such a huge difference and that Release was faster than Debug. I expected release to spend more time on optimizations.

GTEST_USE_OWN_TR1_TUPLE=1
Compiler | Config  | Full     | Compile+Link | Link
clang    | Debug   | 29.975s  | 16.166s      | 10.046s
clang    | Release | 29.621s  | 13.317s      | 0.972s
mingw64  | Debug   | 1m6.751s | 39.590s      | 22.923s
mingw64  | Release | 44.287s  | 15.075s      | 1.031s

GTEST_USE_OWN_TR1_TUPLE=0
Compiler | Config  | Full     | Compile+Link | Link
clang    | Debug   | 28.565s  | 15.815s      | 9.545s
clang    | Release | 28.354s  | 12.955s      | 1.075s
mingw64  | Debug   | 1m7.954s | 37.611s      | 24.304s
mingw64  | Release | 42.615s  | 15.329s      | 0.895s

Further dissection of the build time for the release clang build

#include <gmock/gmock.h>     ~ 2s
Instantiating 11 mocks       ~ 9s
24 test cases                ~ 1s

EDIT:

I followed the advice in the cookbook - Making Compilation Faster, and that helped alot. I also did a comparison with release-1.6.0. I don't know what the consensus is regarding how fast is fast enough (0 seconds, -2 seconds, time travel?). Sub 10 seconds I start feeling is tolerable, 5 seconds is certainly preferred. Ideally, I would like to push this example sub 1 second, but perhaps that's not possible. Given that its a rather simple example, my hunch is that things won't hold under scale, but maybe that's not true.

googlemock 1.7+ ddb8012
GTEST_USE_OWN_TR1_TUPLE=0
Compiler | Config  | Full     | Compile+Link | Link
clang    | Debug   | 31.151s  | 7.572s      | 4.567s
clang    | Release | 39.806s  | 4.742s      | 0.689s

googlemock 1.6
GTEST_USE_OWN_TR1_TUPLE=0
Compiler | Config  | Full     | Compile+Link | Link
clang    | Debug   | 26.551s  | 5.104s      | 3.218s
clang    | Release | 28.932s  | 3.777s      | 0.676s
Leeannaleeanne answered 31/1, 2016 at 1:55 Comment(4)
To really save build time you can use gtest/gmock 1.6 to avoid all the template compilation of 1.7. Not sure about those specific features though, perhaps some are introduced in 1.7.Over
I actually tried 1.6 and didn't find much improvement. But I should re-run the tests and add the numbers to the table to make sure I'm remembering correctly, as I've tried quite a few different configs.Leeannaleeanne
As gtest and gmock sources are fixed, did you considered using a compilation cache, like ccache?Labyrinth
@AntonioPérez I don't know much about ccache, but i don't think it'll help with the incremental build problem, no? Sorry, I didn't mention upfront that was what I was most interested in with this particular post. While I'm developing the test, I must rebuild the test file and relink the executable. But for the build server, or some other scenarios, I imagine it might be extremely useful.Leeannaleeanne

© 2022 - 2024 — McMap. All rights reserved.