Improving build times with Google Mock - c++

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

Related

MSBuild deletes one lib file, breaking the build. Visual Studio works fine

I have project dependencies like this:
Main -> A, Common
A -> B, Common
with the build order:
Common
B
A
Main
The solution builds fine in Visual Studio 2019. But in MSBuild, it builds Common.lib, B.lib, A.lib ... then deletes Common.lib, before trying (and failing) to build Main.exe.
I've tried changing the output dir of Common.lib, but every time MSBuild will build it in the new location, then delete it after A.lib is built. It doesn't delete A.lib or B.lib, even when they're in the same dir as Common.lib. I also have another solution with a different Main project with the same dependencies (A, B and Common), but MSBuild works fine on that.
Any ideas where to start troubleshooting this?
All projects are in C++ with MFC in a static library, using multibyte character set (the solution was upgraded from VC2005). I'm running MSBuild from command line (cmd.exe). Version numbers:
Visual Studio 16.8.5
MSBuild 16.8.3.61104
Update:
The build log using -verbosity:diag as #dxiv suggested now gives this build hierarchy at the end. (I've renamed the projects to match the names above)
============================== Build Hierarchy (IDs represent configurations) =====================================================
Id : Exclusive Time Total Time Path (Targets)
-----------------------------------------------------------------------------------------------------------------------------------
0 : 0.429s 105.369s D:\releases\temp_src\Main.sln (rebuild)
. 1 : 0.270s 104.941s D:\releases\temp_src\Main.vcxproj.metaproj (Rebuild)
| | 2 : 6.218s 31.257s D:\releases\temp_src\A\A.vcxproj (Rebuild)
| | | 3 : 1.600s 1.600s D:\releases\temp_src\B\B.vcxproj (Clean)
| | | 4 : 0.764s 0.764s D:\releases\temp_src\Common\Common.vcxproj (Clean)
| | | 5 : 2.184s 2.184s D:\releases\temp_src\B\B.vcxproj ()
| | | 6 : 2.507s 2.507s D:\releases\temp_src\Common\Common.vcxproj ()
| | | 7 : 0.536s 0.536s D:\releases\temp_src\B\B.vcxproj (GetNativeManifest)
| | | 8 : 0.643s 0.643s D:\releases\temp_src\Common\Common.vcxproj (GetNativeManifest)
| | | 9 : 0.585s 0.585s D:\releases\temp_src\B\B.vcxproj (GetProjectInfoForReference)
| | | 10 : 0.668s 0.668s D:\releases\temp_src\Common\Common.vcxproj (GetProjectInfoForReference)
| | . 11 : 0.549s 0.549s D:\releases\temp_src\Common\Common.vcxproj (GetCopyToOutputDirectoryItems)
| . 12 : 5.923s 10.062s D:\releases\temp_src\Main.vcxproj (Rebuild)
| | | 13 : 0.696s 0.696s D:\releases\temp_src\Common\Common.vcxproj (Clean)
| | | 14 : 1.845s 1.845s D:\releases\temp_src\A\A.vcxproj (GetNativeManifest)
| | | 15 : 0.969s 0.969s D:\releases\temp_src\A\A.vcxproj (GetProjectInfoForReference)
| | . 16 : 0.629s 0.629s D:\releases\temp_src\Common\Common.vcxproj (GetProjectInfoForReference)
ID 13 shows Common.vcxproj being cleaned just as Main begins the rebuild; this seems like the action that deleted the Common.lib. What could cause it to perform this clean?
You should note the build has a order: Common-->B-->A-->Main
If Main project has an error, it will not stop the A and B project's build because they has no error.
Also, if the bottom project Common has an error, when it will break the whole rebuild process, delete A and Main project output files.
Also, when you try tp change the outdir of the four projects, you should right-click on every project Properties-->General-->Output Directories or just modify every outdir properties of vcxproj files. When you rebuild it, it will delete the old location output files and then build again.
In my side, when I run msbuild xxx\xxx.sln -t:clean, it remove the all old previous output files.
If not, I think there are some problems of your current projects. Please try the following steps:
1) remove any project references of these projects and then right-click on the Reference of related projects-->Re-add project Reference
2) re-modify the outdir property under each vcxproj files and then make the value the same.
3) delete .vs hidden folder and any output folders of these four projects.
4) Instead, run msbuild xxx\xxx.sln -t:rebuild to build your solution.
Besides, if my answer did not meet your requirements, please make your issue more clear and use more pics,.... to describe your issue in more detail.

How to run c++ in atom with the atom script package?

I have a windows 10 computer with atom version 1.52.0 and g++ (MinGW.org GCC Build-2) 9.2.0. I can run c++ programs in Atom with the gpp-compiler, but I don't like how the program output is in a new window rather than at the bottom of the Atom window. I'm trying to set up c++ with the script package, but when I run the program with the script package I get the following error.
g++: error: /mnt/c/Users/user/Documents/USACO/2015-2016/December/Silver/test.cpp: No such file or directory
g++: fatal error: no input files
compilation terminated.
I can run java programs with the script package btw. screenshot
A bit late to reply. But for those to come here from Google, on the script package page, it clearly says:
+---------+------------+-----------------+------------------+--------------------+---------------------------------------------------------+
| Grammer | File Based | Selection Based | Required Package | Required in PATH | Notes |
+---------+------------+-----------------+------------------+--------------------+---------------------------------------------------------+
| C++ | Yes | Yes | | xcrun clang++/g++ | Available only on macOS and Linux. Run with -std=c++14. |
+---------+------------+-----------------+------------------+--------------------+---------------------------------------------------------+
Available only on macOS and Linux. Run with -std=c++14.
So, it seems it's not available for Windows. Instead, you can use another package called gpp-compiler:
https://atom.io/packages/gpp-compiler
It works fine on windows:
You'll need to install MinGW and add it to your PATH.

How does "configure" script detect if my system support some header files or cpp feature?

I'm trying to compile google rpc(grpc) on my RHEL 5 box, the configure script checks and throws this error:
configure: error: sched_yield was not found on your system
I checked config.log file and found sth like this:
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char sched_yield ();
| int
| main ()
| {
| return sched_yield ();
| ;
| return 0;
| }
configure:19729: result: no
configure:19736: error: in `/downloads/grpc/third_party/protobuf':
configure:19738: error: sched_yield was not found on your system
Well, it's correct, I did a manual test and is not found. No problem.
But, I just wish to know the principle behind "configure"!
Does "configure" try to generate some c/c++ source code and compile it, in order to see if some features are supported? As you know the "configure" script usually run very fast, much faster than calling a lot of gcc/g++ processes to try headers/features.
So how does "configure" achieve this header/feature "check"?
Does "configure" try to generate some c/c++ source code and compile it, in order to see if some features are supported?
Yes.
As you know the "configure" script usually run very fast [...]
Not in my experience. configure is slowwwwww...
So how does "configure" achieve this header/feature "check"?
See Q #1.

Jenkins - Running test on GUI with VNC - GLX missing

I have a GUI program written in C++ which I need to run Valgrind on. When I setup the VNC server on random display (instance :35) I always run into the same problem:
Xlib: extension "GLX" missing on display ":35".
I've ran this manually and connected to the VNC server and try to run the program with the exact same error message.
glxinfo only shows the same error message. I'm running an openbox-session on the VNC and Gnome on the desktop with Nvidia's proprietary driver.
I'm currently running Fedora 24 on 4.7.9.
Do you guys know how to solve this problem? I've even tried to run the application with vglrun -d :35 ./application with the following error:
Xlib: extension "GLX" missing on display ":35".
Xlib: extension "GLX" missing on display ":35".
[VGL] ERROR: in glXGetConfig--
[VGL] 1071: Could not obtain RGB visual on the server suitable for off-screen rendering
Running nvidia-smi displays the following:
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 367.44 Driver Version: 367.44 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 760 Off | 0000:03:00.0 N/A | N/A |
| 29% 44C P8 N/A / N/A | 308MiB / 1998MiB | N/A Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 Not Supported |
+-----------------------------------------------------------------------------+
What is the problem? How can I solve this?

Which version of libstdc++.so.6 to use?

I'm using a third party shared library (libsw_api.so) on Solaris, which when I try to load, produces the following error:
fatal: relocation error: file libsw_api.so:
symbol _ZNKSt9bad_alloc4whatEv: referenced symbol not found
The program exited with error code 1
When I run ldd on libsw_api.so, all references seem to be fulfilled, specifically the C++ standard library which points to libstdc++.so.6.0.3:
glispa02(fostopr)$ ldd libsw_api.so
...
libstdc++.so.6 => /usr/sfw/lib/libstdc++.so.6
...
glispa02(fostopr)$ ls -l /usr/sfw/lib/libstdc++.so.6
lrwxrwxrwx 1 root root 18 Jun 21 2010 /usr/sfw/lib/libstdc++.so.6 -> libstdc++.so.6.0.3
However that library does not export _ZNKSt9bad_alloc4whatEv,
glispa02(fostopr)$ nm /usr/sfw/lib/libstdc++.so.6 | grep bad_alloc
[7592] | 752340| 64|FUNC |GLOB |0 |2653 |_ZNSt9bad_allocD0Ev
[7324] | 752284| 56|FUNC |GLOB |0 |2652 |_ZNSt9bad_allocD1Ev
[8077] | 752228| 56|FUNC |GLOB |0 |2651 |_ZNSt9bad_allocD2Ev
[7519] | 356736| 76|FUNC |GLOB |0 |473 |_ZSt17__throw_bad_allocv
[7341] | 983588| 12|OBJT |WEAK |0 |3842 |_ZTISt9bad_alloc
[6569] | 777008| 13|OBJT |WEAK |0 |3317 |_ZTSSt9bad_alloc
[7299] | 983568| 20|OBJT |WEAK |0 |3841 |_ZTVSt9bad_alloc
What could be the problem? Wrong version? I'm not really good with C++ on Unix so I'ld appreciate any help.
Could this SPARC32PLUS vs. SPARC mismatch be the cause of the problem?
glispa02(fostopr)$ file libsw_api.so
libsw_api.so: ELF 32-bit MSB dynamic lib SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped
glispa02(fostopr)$ file /usr/sfw/lib/libstdc++.so.6.0.3
/usr/sfw/lib/libstdc++.so.6.0.3: ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped, no debugging information available
My system:
glispa02(fostopr)$ cat /etc/release
Solaris 10 10/09 s10s_u8wos_08a SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 September 2009
glispa02(fostopr)$ uname -a
SunOS glispa02 5.10 Generic_141444-09 sun4u sparc SUNW,SPARC-Enterprise
Hi I'm also upgrading these files, I noticed that I should be using the libstdc++.so.6.0.9 file that comes with the distribution rather than the one in /usr/sfw/lib/
If you use pvs on the libstdc++.so.6 file, it will give you a bunch of entries matching: GLIBCXX, if you don't have an entry matching GLIBCXX_3.4.9, then the symbol bad_alloc::what is not in that library i.e. the library is older than the dependent object libsw_api.so
If this is the case then you probably need a newer version of libstdc++ - it would come with a newer version of g++
I encounter the same issue.
The cause is we export the wrong LD_LIBRARY_PATH
So that our shared library link to the original gcc's library (3.3) instead of our compiler (gcc 4.4).
Fix the linker problem should solve the issue