Skip to content

Exclude setup/teardown from the MemoryManager measurement window (#2149) - #2276

Merged
dmah42 merged 1 commit into
google:mainfrom
devtejasx:fix-memory-manager-measurement-window
Aug 3, 2026
Merged

Exclude setup/teardown from the MemoryManager measurement window (#2149)#2276
dmah42 merged 1 commit into
google:mainfrom
devtejasx:fix-memory-manager-measurement-window

Conversation

@devtejasx

@devtejasx devtejasx commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

RunMemoryManager() opened the MemoryManager window before allocating the ThreadManager and running the per-benchmark Setup(), and closed it after Teardown(). Everything the library and the fixture allocate around the benchmark was therefore attributed to the benchmark itself, so an exact allocation count was impossible to obtain.

Move Start()/Stop() to bracket only RunInThread(), which is the same region the timers cover. Setup()/Teardown() already run outside the timed region, so this makes the memory window consistent with the time window.

Add memory_manager_ordering_gtest, which registers a MemoryManager that records whether the window is open and asserts the fixture callbacks never observe it as open. It fails on the previous ordering ("Teardown ran inside the MemoryManager Start/Stop window") and passes with this change.


Per AGENTS.md: AI-assisted — the patch was drafted with AI assistance
(Claude) and then reviewed, tested, and understood by me. I take full
responsibility for it.

Comment thread src/benchmark_runner.cc Outdated
std::unique_ptr<internal::ThreadManager> manager;
manager.reset(new internal::ThreadManager(1));
b.Setup();
MemoryManager::Result memory_result;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why have you moved the declaration of the result?

Comment thread src/benchmark_runner.cc Outdated
MemoryManager::Result BenchmarkRunner::RunMemoryManager(
IterationCount memory_iterations) {
memory_manager->Start();
// Set up the thread manager and run the user's Setup() outside the

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this a useful comment or just the AI spewing the decisions its made?

Comment thread test/memory_manager_ordering_gtest.cc
…gle#2149)

RunMemoryManager() opened the MemoryManager window before allocating the
ThreadManager and running the per-benchmark Setup(), and closed it after
Teardown(). Everything the library and the fixture allocate around the
benchmark was therefore attributed to the benchmark itself, so an exact
allocation count was impossible to obtain.

Move Start()/Stop() to bracket only RunInThread(), which is the same region
the timers cover. Setup()/Teardown() already run outside the timed region, so
this makes the memory window consistent with the time window.

Add memory_manager_ordering_gtest, which registers a MemoryManager that
records whether the window is open and asserts the fixture callbacks never
observe it as open. It fails on the previous ordering ("Teardown ran inside
the MemoryManager Start/Stop window") and passes with this change.
@devtejasx
devtejasx force-pushed the fix-memory-manager-measurement-window branch from 58c470a to 32d4edd Compare August 3, 2026 09:45
@devtejasx

Copy link
Copy Markdown
Contributor Author

All three addressed; the runner change is now a four-line move.

  • The memory_result declaration is back where it was. I had moved it on the issue author's suggestion, in case Result ever allocates. Nothing in the fix needs it, so it was noise.
  • Comment dropped.
  • On the test. It registers a MemoryManager that flips a flag in Start()/Stop(), and a benchmark whose Setup()/Teardown() assert that flag is false. Against main it fails with Teardown ran inside the MemoryManager Start/Stop window; with this change it passes. What it pins is the ordering the PR is about: nothing else in the suite observes when the measurement window opens relative to Setup(), so moving Start() back above b.Setup() in a later refactor would go unnoticed. If you would rather not carry it, I'll drop it and leave just the runner change.

@dmah42
dmah42 merged commit 977dfc2 into google:main Aug 3, 2026
92 checks passed
@dmah42

dmah42 commented Aug 3, 2026

Copy link
Copy Markdown
Member

thanks

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants