Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

need to improve compilation speed #68

Closed
GoogleCodeExporter opened this issue Oct 1, 2015 · 12 comments
Closed

need to improve compilation speed #68

GoogleCodeExporter opened this issue Oct 1, 2015 · 12 comments

Comments

@GoogleCodeExporter
Copy link

Code using gmock is often slow to compile.  In MSVC at least, the
compilation time is often proportional to the number of mock methods used.
 gmock-generated-function-mockers_test.cc can take ~20 seconds to compile
using VC.  gcc does better but still needs ~10 seconds.

Some users need to mock some big interfaces that have hundreds of virtual
methods.  It can take the compiler several minutes to compile a test in
such cases, which is not acceptable.  We need to find ways to improve the
compilation speed.  One idea is to separate the declaration and definition
of mock methods such that the mock class only needs to be compiled once.

Original issue reported on code.google.com by zhanyong...@gmail.com on 11 Sep 2009 at 4:05

@GoogleCodeExporter
Copy link
Author

This is a serious issue for the SlimDX project which is using gmock.  SlimDX is 
a 
managed interop layer, so we can't turn off /clr for our tests.

Original comment by legal...@xmission.com on 4 Mar 2010 at 4:51

@GoogleCodeExporter
Copy link
Author

Unfortunately, I looked through the implementation and didn't see obvious 
things we
can do to improve the compilation speed meaningfully.  Perhaps our best bet is
Moore's Law. :-)

I consider it an MSVC bug that /clr causes compilation time to multiply.  Not 
sure
what we can do about it....

Seriously, if someone wants this fixed, he'll probably need to be prepared to 
write a
patch himself.

Original comment by w...@google.com on 4 Mar 2010 at 5:27

@GoogleCodeExporter
Copy link
Author

No easy solution in sight.

Original comment by w...@google.com on 6 Mar 2010 at 5:51

  • Added labels: Priority-Low
  • Removed labels: Priority-Medium

@GoogleCodeExporter
Copy link
Author

Original comment by w...@google.com on 5 Jun 2010 at 6:41

  • Changed state: WontFix

@GoogleCodeExporter
Copy link
Author

Before discovering google mock, we implemented a similar mocking (but less 
featured) framework in-house 
that uses many of the same techniques as google mock.  Due to the heavy 
template instantiation, the long 
compile time is almost unavoidable unless templates are stripped out and we use 
code-generating techniques 
instead, essentially providing what is similar in concept to pre-compiled 
templates.

Unfortunately, most people who would use mocks are also interested in the fast 
test-compile-develop-
compile cycles, so this is a real problem.

We originally used boost::tuple along with boost::variant and that was killer 
on the compile time.  When we 
substituted out boost::variant with boost::any, that helped a lot with the 
compile time and obviously 
introduced a slight (negligible) runtime burden.  


Original comment by chu.e...@gmail.com on 5 Jun 2010 at 2:53

@GoogleCodeExporter
Copy link
Author

Issue 33 has been merged into this issue.

Original comment by w...@google.com on 18 Oct 2010 at 6:50

@GoogleCodeExporter
Copy link
Author

Reopened based on recent request from Chromium.

Original comment by w...@google.com on 18 Oct 2010 at 6:52

  • Changed state: Accepted
  • Added labels: Priority-High
  • Removed labels: Priority-Low

@GoogleCodeExporter
Copy link
Author

Nico Weber:

Compiling a single line like 

MOCK_METHOD1(f5, void(int i)); 

takes about 0.1s on my machine. Behind the scenes, this causes an (apparently 
hefty) template instantiation. The compiler caches it for this type, so having 
more MOCK_METHOD1s with the same signature is almost free. But if the signature 
is different, it's 0.1s for every one of these MOCK_METHODs. 

Now look at Chromium's gl_mock.h . It contains about 150 MOCK_METHOD lines! 
Building a cc file that includes this file and does nothing else takes 12 
seconds and 500 MB of ram on my machine.

Elliot Glaysher:

As a test, I just created a gl_mock.cc file that moved just the ctor/dtor to 
the cc file: the dot o file was 30 megs. I wonder if there's some possible 
speed up gains here.Oct 14

Nico Weber:

Elliot Glaysher, Nice find! Moving the constructor and destructor of gl_mock 
out-of-line cuts the compile time more than in half (12s -> 5s) and memory 
usage goes from 500 mb to 160 mb. Still slow, but better.

Original comment by w...@google.com on 18 Oct 2010 at 7:02

@GoogleCodeExporter
Copy link
Author

It takes me 15 seconds to compile a small test file that uses 6 mock classes.  
Compiler is gcc 4.2.1 on Mac OS X 10.6.4.  Each class is relatively small.  The 
largest has around 10 mock methods but most of them have 5 or less.  The test 
itself consists of 6 very small test methods, each is less than 10 lines of 
code.  My project is currently very small but I've only just begun.

It was stated (Issue 33?) that the mock class is entirely defined in the header 
file to make it convenient to use.  However, I pose the argument that the 
compile time burden that this causes may actually makes it less convenient 
because I am forced to decide on a method-by-method basis whether or not to 
mock it.

I am able to easily auto-generate mock classes from defined interfaces using 
the included gmock_gen.py script with a wrapper around it.  I can generate the 
mock class for many interfaces and include them as needed in unit tests.  There 
would be no need to pick and choose which methods need to be mocked and the 
process of generating the mocks would be simple.  The process of discerning 
which methods should be mocked and which ones need not be mocked is not trivial 
and becomes more difficult when the mock class is needed in a number of 
different unit tests.

I would like to use Google Mock.  There is some really great stuff in here and 
I love the ability to jump in and write code to defined interfaces.  The time 
to compile it may kill it for me, though.

Original comment by c...@ecbaldwin.net on 12 Nov 2010 at 5:38

@GoogleCodeExporter
Copy link
Author

I have a huge patch waiting for Nico's review.  In Nico's testing, it speeds up 
the compilation of Chromium's tests that use Google Mock by ~2.6x.  Note that 
this speed-up is for the entire build process.  Since the build also contains 
non-Google-Mock code, the actual speed-up for Google-Mock should be higher: it 
can be 5x or more in some of my experiments.

Original comment by w...@google.com on 16 Feb 2011 at 8:02

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

I also wrote a recipe about a technique that you can use (with or without my 
pending patch) to speed up the compilation: 
http://code.google.com/p/googlemock/wiki/CookBook?ts=1297881104&updated=CookBook
#Making_the_Compilation_Faster.  Elliot Glaysher was the first one to suggest 
this technique.

Original comment by w...@google.com on 16 Feb 2011 at 6:34

@GoogleCodeExporter
Copy link
Author

With r359, the compilation should be much faster.  Thanks to Nico Weber for the 
code review.

Original comment by w...@google.com on 23 Feb 2011 at 7:40

  • Changed state: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant