[Bug]: Extensive memory usage of gmock with Clang compilers [1.12.0 regression] #4156
Comments
trzecieu
changed the title
trzecieu
changed the title
|
Just a shot in the dark from a quick glance at the commit, but I wonder if the change from "untyped" to "typed" ( Also note that if you can run Clang with |
|
Thanks @higher-performance for the suggestion with Optimal (either version 1.11.0, or version with reverted commit 9d21db9) Suboptimal (Version 1.12.0+) As you can see there is an extraordinary amount of overhead coming from Those are traced from: and cascade to: Which in my case is: // ...
const Cleanup report_uninteresting_call(
[&] { ReportUninterestingCall(reaction, ss.str()); }); // <===== 1770
// ...
const Cleanup handle_failures([&] { // <===== 1814
ss << "\n" << why.str();
if (!found) {
// No expectation matches this call - reports a failure.
Expect(false, nullptr, -1, ss.str());
} else if (is_excessive) {
// We had an upper-bound violation and the failure message is in ss.
Expect(false, untyped_expectation->file(), untyped_expectation->line(),
ss.str());
} else {
// We had an expected call and the matching expectation is
// described in ss.
Log(kInfo, loc.str() + ss.str(), 2);
}
}); |
|
Thanks for confirming. I think I may have tracked it down. The problem indeed seems to stem from They require using functors outside the templates. I'm looking into that now. |
The slowdown appears to be due to an implicit conversion of distinct (yet semantically identical) lambdas to `std::function`. Lifting out the lambdas into functors that don't get re-instantiated reduces compilation times by nearly half. Fixes google#4156 PiperOrigin-RevId: 523447948 Change-Id: Ib0ae0761a54d7b1f2b706b14b2858eedf47e2297
Describe the issue
Hello,
We've noticed that gmock 1.12.0+ started to require much more system memory and time to compile. This issue affects only clang compilers:
Possibly some versions in between. Standard 86-64 Linux clang shows a similar tendency, but memory consumption is smaller.
I do understand this is a bug on the edge of code/compiler bug. But still I'd like to highlight this as a potential problem that might affect silently everyone that uses google tests.
Some graphs with memory consumption over time:
Emscripten 2.0.0 (clang version 12.0.0) + googletest 1.10.0
Emscripten 2.0.0 (clang version 12.0.0) + googletest 1.12.1
Emscripten 3.1.31 (clang version 17.0.0) + googletest 1.10.0
Emscripten 3.1.31 (clang version 17.0.0) + googletest 1.12.1
Ubuntu clang version 14.0.0-1ubuntu1 + googletest 1.10.0
Ubuntu clang version 14.0.0-1ubuntu1 + googletest 1.12.1
g++ (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 + googletest 1.10.0
g++ (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 + googletest 1.12.1
Consistently 1.12.1 consumes much more memory. With this synthetic example, it is approaching 350MiB, but in a production code, these values are exceeding hardware capabilities. Here are graphs from 1 compilation unit from our production code:
1.10.0 (~1GiB, ~25s to compile)
1.12.1 (~3GiB, ~75s to compile)
Steps to reproduce the problem
This issue is especially visible if one compilation unit contains a several semi-complicated mock classes.
The synthetic test can be done with:
What version of GoogleTest are you using?
Last good version: 1.11.0
First broken version: 1.12.0
To be precise, this issue was introduced/exaggerated with this commit 9d21db9
CC: @jacobsa
What operating system and version are you using?
But this also is visible on macOS Monterey/Ventura with Xcode 13/14
What compiler and version are you using?
Blocker:
Major:
What build system are you using?
N/A
Additional context
No response
The text was updated successfully, but these errors were encountered: