PEP 831: Frame pointers by pablogsal · Pull Request #4896 · python/peps

pablogsal · 2026-04-09T22:01:21Z

Basic requirements (all PEP Types)

Standards Track requirements

📚 Documentation preview 📚: https://pep-previews--4896.org.readthedocs.build/pep-0831/

peps/pep-0830.rst

savannahostrowski

Given the numbers we've seen, we should update 0.5-2%...if we're rounding up?

peps/pep-0830.rst

peps/pep-0831.rst

hugovk

Formatting suggestions.

peps/pep-0831.rst

markshannon

Very compelling.

I'd added a few quick comments on the first part of the PEP.

This is long, and might be a bit much to expect anyone to read through in one go.
Maybe some of the supporting analyses could be moved into appendices and linked to from the body of the PEP?

For example, the detailed, but long, analyses of perf and ebpf tools could be moved to appendices.

peps/pep-0831.rst

markshannon · 2026-04-10T08:17:37Z

peps/pep-0831.rst

+above) prevents these tools from producing useful call stacks for Python
+processes, and undermines the perf trampoline support CPython shipped in 3.12.
+
+The measured overhead is under 2% geometric mean for typical workloads.


For what platform, build configuration, etc, etc?
Can you link to the data, otherwise the readers (at least this reader's) first thought is "where's the evidence?"

Added a cross-reference to the Backwards Compatibility section which has the full per-platform table (8 machines across arm64 and x86-64, geometric mean across 80 pyperformance benchmarks). The abstract is intentionally concise but now points readers to the evidence.

markshannon · 2026-04-10T08:39:34Z

peps/pep-0831.rst

+==========
+
+Python's observability story (profiling, debugging, and system-level tracing)
+is fundamentally limited by the absence of frame pointers. The core motivation


This isn't quite true. It isn't impossible without frame pointers, just much, much harder.

The text says "fundamentally limited", not impossible, no?

markshannon · 2026-04-10T08:40:27Z

peps/pep-0831.rst

+The performance wins that profiling enables far outweigh the modest overhead of
+frame pointers.  As Brendan Gregg notes: "I've seen frame pointers help find
+performance wins ranging from 5% to 500%" [#gregg2024]_.  A 0.5-2% overhead that
+unlocks the ability to find 5-500% improvements is a favourable trade.


Make it clear, that large speedups are not going to happen for CPython, but it might happen for larger systems using Python as a glue language.

Good catch. Clarified that the 5-500% wins Gregg describes come from identifying hot paths in production systems, not from enabling frame pointers on CPython itself.

markshannon · 2026-04-10T08:43:31Z

peps/pep-0831.rst

+frame also stores the *previous* frame pointer, creating a linked list through
+the entire call stack::
+
+    ┌──────────────────┐


Have the arrows actually point to the previous frame. I think it is OK to use an image,instead of ASCII art.

Yeah perhaps an image may be better.

Just to clarify: The arrows do point to the previous frame as each saved %rbp ──► points to the frame above it (i.e. its caller), which is the correct direction for a frame-pointer chain. The chain walks up (toward main). I can look into replacing with an image if the ASCII art is unclear, but it would complicate the diff/review cycle. Open to suggestions.

peps/pep-0831.rst

markshannon · 2026-04-10T08:52:48Z

peps/pep-0831.rst

+default [#gcc_fomit]_.  This frees the ``%rbp`` register for general use,
+giving the optimiser one more register to work with. On x86-64 this is a gain
+of one register out of 16 (about 7%).  The performance benefit is small
+(typically 0.5-2%) but it was considered worthwhile when the convention was


Again, you need to be more nuanced about how much things slow down, and for which platforms.

I'd use terms like "a few" rather than 0.5-2 and add a link to a section with a more detailed breakdown

Changed to "typically a few percent" and added a cross-reference to the detailed analysis section which has the full platform-by-platform breakdown.

markshannon · 2026-04-10T08:53:47Z

peps/pep-0831.rst

+established for 32-bit x86, where the gain was one register out of 6 (~20%).
+
+Without frame pointers, the linked list does not exist.  Tools that need to
+walk the call stack must instead parse DWARF debug information (a complex,


Don't forget Windows. It would make your case more compelling, as tools would need to parse DWARF and understand what Windows does.

Good point. Added a mention of Windows .pdata / .xdata unwind metadata alongside DWARF.

markshannon · 2026-04-10T08:55:11Z

peps/pep-0831.rst

+follows the chain, and reconstructs the full call stack in microseconds.  This
+is fast enough to sample at 10,000 Hz in production with negligible overhead.
+
+Without frame pointers, the profiler must fall back to DWARF unwinding, a


Didn't you just say this a few paragraphs earlier?
https://github.com/python/peps/pull/4896/changes#diff-cce3082fa07cd352af453f46a4e6f23b15645c79d58cb902da789f5c463cc92aR115

The earlier mention (in "What Are Frame Pointers?") is a brief general overview; this section ("Profilers Are Slower...") dives into the specific profiler impact with data (55x larger perf.data, 210x slower unwinding, etc.). Some overlap is intentional as the first establishes the concept, the second builds the quantitative case. I could trim the first mention further if you think it's too redundant.

Co-authored-by: Mark Shannon <Mark.Shannon@arm.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

pablogsal · 2026-04-11T00:21:18Z

Thanks for the thorough review Mark! Addressed all the inline comments (cross-references to data, clarified the Gregg quote, softened language, added Windows mention, etc). Re: length and moving content to appendices, that is a fair point. I will move the eBPF and perf investigation to the appendix.

hugovk · 2026-04-11T11:26:22Z

.pre-commit-config.yaml

        args: [--fix=lf]
      - id: trailing-whitespace
        name: "Remove trailing whitespace"
+        exclude: .*\.svg


@Fidget-Spinner Did this break the SVGs? They're code, so it's usually okay to allow this.

Suggested change

exclude: .*\.svg

Yes they break the svgs

Wait let me correct, I'm not sure if they break it but its very disruptive to reformat svgs

pablogsal requested review from a team and brettcannon as code owners April 9, 2026 22:01

pablogsal and others added 13 commits April 9, 2026 23:03

Frame pointers frame pointers frame pointers

23ea4a5

First pass at edits

984672f

Add ref back

42c762a

Fix flame graph

2025921

Fixed whitespace

3408a2b

Update preamble

4569c5c

Add RPi and M3 results

6c3bde4

Clean up table

87a3af7

Add my benchmarks

2f241a5

Add perf figures, tighten JIT claims

941880e

remove Diego (for now)

009204a

fix typo

bd948d0

Show outliers

02c94e6

pablogsal force-pushed the frame-pointers branch from fd3ea6c to 7c64cc2 Compare April 9, 2026 22:03

pablogsal changed the title ~~Frame pointers~~ PEP 830: Frame pointers Apr 9, 2026

Update pep-0830.rst

1c19495

pablogsal force-pushed the frame-pointers branch from 7c64cc2 to 1c19495 Compare April 9, 2026 22:06

Small fixes

957cecb

brianschubert added the new-pep A new draft PEP submitted for initial review label Apr 9, 2026

brianschubert reviewed Apr 9, 2026

View reviewed changes

peps/pep-0830.rst Outdated Show resolved Hide resolved

savannahostrowski requested changes Apr 9, 2026

View reviewed changes

peps/pep-0830.rst Outdated Show resolved Hide resolved

peps/pep-0830.rst Outdated Show resolved Hide resolved

peps/pep-0830.rst Outdated Show resolved Hide resolved

peps/pep-0830.rst Outdated Show resolved Hide resolved

peps/pep-0830.rst Outdated Show resolved Hide resolved

Address PR feedback

e7faa8c

pablogsal changed the title ~~PEP 830: Frame pointers~~ PEP 831: Frame pointers Apr 9, 2026

JelleZijlstra reviewed Apr 10, 2026

View reviewed changes

peps/pep-0831.rst Outdated Show resolved Hide resolved

hugovk reviewed Apr 10, 2026

View reviewed changes

markshannon reviewed Apr 10, 2026

View reviewed changes

Fidget-Spinner added 2 commits April 11, 2026 00:39

Update new results, add alt text

b231f21

exclude svg from pre-commit

9360134

Fidget-Spinner and others added 2 commits April 11, 2026 00:44

Update .pre-commit-config.yaml

c7269af

Merge pull request #9 from Fidget-Spinner/fp-kj-3

42dcac9

pablogsal requested a review from CAM-Gerlach as a code owner April 10, 2026 18:53

Apply suggestions from code review

df300e1

Co-authored-by: Mark Shannon <Mark.Shannon@arm.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>

Apply suggestions

3b8af0a

mjoody20 approved these changes Apr 11, 2026

View reviewed changes

hugovk reviewed Apr 11, 2026

View reviewed changes

Uh oh!

Conversation

pablogsal commented Apr 9, 2026 • edited by hugovk Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Basic requirements (all PEP Types)

Standards Track requirements

Uh oh!

Uh oh!

savannahostrowski left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hugovk left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

markshannon left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pablogsal commented Apr 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

pablogsal commented Apr 9, 2026 •

edited by hugovk

Loading

pablogsal commented Apr 11, 2026 •

edited

Loading