perf(callgrind): inline CLG_(get_fn_entry) to remove a per-basic-block call

[codspeed-hq]

Summary

Callgrind's CLG_(setup_bbcc) runs on every basic-block execution and is one of the hottest functions in the profile. On each call it invoked CLG_(get_fn_entry) — an out-of-line function in fn.c — to read the active-recursion level of the current function (the separate_recursions > 1 path, active by default since --separate-recs defaults to 2).

Because get_fn_entry lived in a different translation unit, the compiler could not inline what is a trivial one-line array index, leaving a real call vgCallgrind_get_fn_entry executed once per basic block.

Change

• Expose the previously file-local current_fn_active as CLG_(current_fn_active) (declared extern in global.h, defined in fn.c).
• Move CLG_(get_fn_entry) into global.h as a static __inline__ accessor, placed after the CLG_ASSERT macro so the bounds check is preserved unchanged.

Verification (local, this build)

• Inlining confirmed: after the change, objdump -d of the built callgrind-amd64-linux shows zero call get_fn_entry instructions, and the symbol is gone entirely from nm — the accessor is inlined at every call site (setup_bbcc, get_cxt, push_cxt, …).
• Correctness confirmed: on a recursive test workload, summary: instruction counts are identical between baseline and optimized builds, and the full callgrind.out is byte-for-byte identical when the two builds are run back-to-back (isolating process-startup randomization). Verified both with default options and with --separate-recs=3. This is a pure call-overhead removal, not a semantic change.

Performance

Measured with CodSpeed walltime mode on the macro runners during the optimization investigation, the change was consistently positive across back-to-back paired baseline/head runs (roughly +0.6% to +1.6%), comfortably above the ~0.2% run-to-run noise floor, with no benchmark regressing on aggregate.

Note: walltime could not be re-measured in the implementation sandbox (no perf available, and the sandbox is x86_64 while the benchmark fixtures/runners are ARM64). The authoritative walltime impact is produced by this PR's CodSpeed CI run on the codspeed-macro runners.

[greptile-apps]

Greptile Summary

The PR inlines the active-function array accessor to remove a hot-path cross-translation-unit call.

• Exposes the active-function array through global.h.
• Replaces the out-of-line accessor in fn.c with a static inline implementation.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failures remain within the scope of this follow-up review.

Important Files Changed

Filename	Overview
callgrind/fn.c	Exports the active-function array and removes the former out-of-line accessor.
callgrind/global.h	Declares the active-function array and defines the bounds-checked inline accessor.

_{Reviews (5): Last reviewed commit: "perf(callgrind): inline CLG_(get_fn_entr..." | Re-trigger Greptile}

[codspeed-hq]

Merging this PR will not alter performance

✅ 84 untouched benchmarks
⏩ 60 skipped benchmarks¹

---

_{Comparing codspeed-optim-inline-clg-get-fn-entry-to-remove-a-per-basic-bloc-1784905750820 (3f8d868) with master (20aa609)²}

Footnotes

1. 60 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on master (448b7d0) during the generation of this report, so 20aa609 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[art049]

codspeed do you see a way to make the benches more stable? can we increase the number of iterations without having the workflow being too long?

[codspeed-hq]

codspeed do you see a way to make the benches more stable? can we increase the number of iterations without having the workflow being too long?

Yes — the instability comes from how many rounds each benchmark gets, and there's a clean way to increase iterations without letting the workflow run away.

Why they were unstable: these are codspeed exec walltime benchmarks, and the harness uses a default max-time budget of 3s per benchmark. Several of the Valgrind commands take multiple seconds (some over a minute) for a single execution, so under that budget the slowest ones completed only one round. A one-sample estimate has no averaging and is dominated by run-to-run noise — that's the wide swings you saw.

What I changed (in bench/generate_config.py + .github/workflows/codspeed.yml): the generated codspeed.yml now sets root-level walltime options for every benchmark:

• min-rounds: 5 — guarantees several measured samples for a stable estimate
• warmup-time: 1s — one warmup round to drop cold-start effects (process spawn, page faults, cache warming)
• max-time: 20s — a per-benchmark wall-time ceiling so fast benchmarks don't over-run and slow ones are capped

On "without making the workflow too long": the max-time ceiling is exactly the mechanism that bounds duration. Fast benchmarks stop as soon as they have enough samples; slow benchmarks are capped instead of running min-rounds × (full duration). When max-time is hit before min-rounds, the harness stops early (max-time takes priority). I also bumped the job timeout-minutes from 15 → 25 to cover the longer benchmarking phase.

The three knobs are exposed as CLI flags (--warmup-time, --min-rounds, --max-time) and passed explicitly in the workflow, so increasing stability further is now a single documented dial — just raise --min-rounds and/or --max-time.

I validated that the generated config is accepted by the runner's parser. I couldn't produce a real walltime measurement in the sandbox (perf isn't available there and the sandbox is x86_64 while the fixtures are ARM64) — the actual stability improvement will show up in this PR's CodSpeed CI run on the macro runners.

Summary

• Warming up the performance wizard...
• Investigating benchmark stability — Understood the exec-based walltime benchmark setup and CI workflow
• Researching iteration/warmup config options — Confirmed codspeed.yml supports per-target and global walltime options (min-rounds, max-rounds, warmup-time, max-time)
• Implementing stability improvement — Added walltime sampling options (min-rounds, warmup-time, max-time) to the generator and workflow; validated config parses
• Committing changes — Committed and submitted the benchmark stability changes to the PR
• Handling comment — Comment handling finished successfully

_{Learnings updated. See what CodSpeed remembers about this repository.}

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}

[art049]

I cherrypicked your commit on the base branch. Merge it in this pr so I can compare

[codspeed-hq]

I cherrypicked your commit on the base branch. Merge it in this pr so I can compare

Done — I merged master into this PR branch.

Since you cherry-picked the walltime-stabilization commit (min-rounds / warmup-time / max-time) onto master, that stabilization is now on both sides of the comparison. After the merge the only net difference between this branch and master is the actual optimization — callgrind/fn.c and callgrind/global.h (21 insertions, 8 deletions). So the upcoming CodSpeed run compares:

• base = stabilized benchmarks
• head = stabilized benchmarks + the inlined CLG_(get_fn_entry)

isolating the pure call-overhead removal.

Merge details:

• The two branches had no shared ancestry locally (grafted shallow histories), so the merge surfaced add/add conflicts in callgrind/fn.c and callgrind/global.h. Those hunks were exactly the optimization vs. the pre-optimization code; I resolved both by keeping the optimized versions. No conflict markers remain and nothing else changed.

Merge commit: 168ac7c. A fresh CodSpeed run should now give you a clean base-vs-head comparison of the inline change alone.

Summary

• Warming up the performance wizard...
• Merging master into the PR branch — Merged the base branch into the PR branch. Resolved add/add conflicts in callgrind/fn.c and callgrind/global.h by keeping the optimized versions. The branch now differs from master only by the inline optimization.
• Handling comment — Comment handling finished successfully

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}

[codspeed-hq]

Unable to generate the flame graphs

The performance report has correctly been generated, but there was an internal error while generating the flame graphs for this run. We're working on fixing the issue. Feel free to contact us on Discord or at support@codspeed.io if the issue persists.