Compile performance suggestions? #3508
Unanswered
sopgenorth
asked this question in
Community Help
Replies: 3 comments
-
Huh: http://google.github.io/googletest/gmock_cook_book.html#making-the-compilation-faster With this in place for about 50 of the Mock classes we use, our unit tests build about 3x faster. From some more profiling work I did on this, it's looking like the next big compile-time hit is when we make use NiceMock<>. Just need to work out what "soon" means in this comment: |
Beta Was this translation helpful? Give feedback.
0 replies
-
Do you create new android |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I've seen a handful of issues here with long compile times, and it seems clear that this doesn't have an obvious or trivial solution available. This also shows that it clearly needs someone both bothered enough by the long build times, and with the desire to profile builds to first work out the core sources of lengthy build times.
For a project I work on, our unit test build makes heavy use of gmock and gtest. With some of the heavily mocked C++ files, well over 100 of these files using Mocks take more than 30 seconds to build, and around 30 of those are over a minute each. Here I started by doing a simple profiling of all of our build files by adding a 'time' command to the g++ calls.
The first optimization I looked at was removing optimizations on unit test code (tested release code can remain the same) helped pretty significantly. Normally our project would build everything with -O2, but switching that out for -Og cut the time in about half for the build (-O1 was similar, but a little slower)
Next, I was hopeful that grouping together a lot of the common Mock classes together in a single header, and then using pre-compiled headers would help. This seemed to maybe shave a little time off, but nothing terribly significant.
My next crazy thought was to split up the MOCK_METHOD macro to have a header file option (simplified for creating the class definition), and an IMPL macro. The target usage would be function signature declarations in the header with "MOCK_METHOD_HEADER()", with a corresponding C++ file that uses something like "MOCK_METHOD_IMPL()". With a few manually expanded functions to match the GMock needed interface, this strategy was at least able to build, though I haven't converted enough Mocks quite yet to concretely say if this would actually help.
The initial GCC profiling on the builds are also showing that a lot of the time is spent on templates, so the above header/impl strategy might be fruitless, and may instead benefit from methods to reduce template use, pre-instantiate them, or go for some sort of pIMPL style usage. Perhaps an intermediate GMock/GTest parser to simplify things for the compiler? Profiling the build further might provide better insights with a tool like: https://github.com/mikael-s-persson/templight
So, has anyone else here ever tried to work out the core source of the Mock compile-time usage? Do any of the approaches above seem to have any potential? Do you have other ideas to try out but haven't had the time to try them yet?
Or are long compile times with Mocks and C++ just inevitable and I should be thankful they aren't longer, and instead left with max out hardware and other techniques like ccache/distcc?
Beta Was this translation helpful? Give feedback.
All reactions