Closed GoogleCodeExporter closed 8 years ago
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
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
No easy solution in sight.
Original comment by w...@google.com
on 6 Mar 2010 at 5:51
Original comment by w...@google.com
on 5 Jun 2010 at 6:41
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
Issue 33 has been merged into this issue.
Original comment by w...@google.com
on 18 Oct 2010 at 6:50
Reopened based on recent request from Chromium.
Original comment by w...@google.com
on 18 Oct 2010 at 6:52
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
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
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
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
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
Original issue reported on code.google.com by
zhanyong...@gmail.com
on 11 Sep 2009 at 4:05