Performance overhead of Scalar::Weak in high-frequency Perl loops

Short answer

There is no universal number for the CPU overhead of Scalar::Weak — it depends on your Perl version, build options, and loop body — but the well-established behavior is this: weakening a reference and later releasing it adds a small, roughly constant cost per reference operation, not per object in the graph. In micro-benchmarks on modern Perls (5.30+), the difference typically lands in the low single-digit percent range for allocation-heavy loops. The only trustworthy figure is the one you measure on your own workload, so the practical answer is a benchmark recipe, not a constant.

Likely explanation vs. confirmed facts

Confirmed behavior: Perl stores the weak flag on the individual scalar value (SV). A weak reference does not increment the referent's reference count, so when the last strong reference goes away, the referent is freed and all weak references to it are automatically undefined. The bookkeeping Perl does for this — checking the weak flag on assignment and walking the weak-reference list at destruction — is per-SV work.

Likely explanation (not verified here): Because that bookkeeping is per-SV, overhead should scale with the number of reference assignments your loop performs, not with the depth or total size of the object graph. A deep graph with few reassignments costs about the same per operation as a flat one. Treat the specific magnitude (often quoted around 1–2% in tight loops) as a hypothesis to verify, since XS code, custom allocators, and Perl version differences can shift it.

A minimal benchmark for your case

use Benchmark qw(cmpthese);
use Scalar::Util qw(weaken);

sub make_plain { my $n = {}; $n->{next} = $n; return $n; }
sub make_weak  { my $n = {}; $n->{next} = $n; weaken($n->{next}); return $n; }

cmpthese(-5, {
  plain => sub { make_plain() for 1..10_000 },
  weak  => sub { make_weak()  for 1..10_000 },
});

Run each variant several times and compare the spread, not a single run — Perl's reference-count traffic and allocator behavior add noise. Keep the loop body identical except for the weaken() call so you isolate the weak-reference cost.

Seeing the reference-count picture

Perl doesn't expose a built-in counter of refcount increments/decrements, but you can inspect individual SVs:

• Devel::Peek::Dump $ref shows the REFCNT field; a refcount that stays above zero after you expected cleanup signals a cycle.
• Devel::Cycle directly reports circular references in a structure — cheaper than reasoning from raw refcounts.
• For CPU attribution, Devel::NYTProf at statement or subroutine level will show whether weaken() and destruction paths are hot; it won't isolate per-opcode refcount work.

If memory grows across iterations with plain references and stays flat with weak ones, the cycle — not the weak-reference bookkeeping — is your real bottleneck. Manual cleanup (DESTROY breaking the cycle) avoids the per-assignment weak-ref cost but adds its own teardown cost and fragility.

Recommendation

In high-frequency loops that allocate and release many objects, prefer weak references when cycles are possible: the per-operation overhead is small and constant, while a leaked cycle costs unbounded memory and eventual full-structure cleanup. Only switch to manual cleanup if your own benchmark shows the weak-ref path is measurably hot. The one detail that would change this advice: whether your loop is dominated by reference assignment (weak refs cost more) or by destruction (weak refs usually win).

Note: overhead figures here are model-knowledge estimates, not measurements from your environment. Verify with the benchmark above on your target Perl before deciding.