RStudio's Profiler Tab Made Measure-First the Default — Are Its Memory Columns Safe to Tune Against?

Since the 0.99-era IDE releases (circa 2015 — the exact build is worth confirming in Posit's release notes), RStudio has shipped a built-in Profiler built on the profvis package. Profile > Start Profiling samples the call stack of the current R session and renders an interactive flame graph in a dedicated Profiler tab, which turned "measure before you optimize" into the documented workflow rather than an ad-hoc timing exercise.

The unresolved piece is the memory columns shown alongside the time axis. The goal is deciding whether allocation tuning based on those numbers is defensible. They record allocation and garbage-collection events at sampling granularity, so a spike may reflect when the sampler happened to observe GC rather than memory that is actually retained. Two boundaries compound the ambiguity: compiled C/C++/Fortran time appears only under the .Call or primitive wrapper that invoked it, and parallel workers or background R processes are not captured at all, so the flame graph can reshape where the real cost lives.

Before acting on a profile:

1. Are the memory columns precise enough to guide allocation tuning, or directional only?
2. Does the bundled profvis version change how memory is aggregated independently of the IDE version?
3. Would cross-checking a suspect spike against R's own memory reporting reliably separate GC-timing artifacts from genuinely retained allocations?