Thanks Alex. I appreciate the feedback and I understand the concern about tone.
To clarify: my comment about OKR-driven development wasn’t idle speculation. I’ve had direct conversations with Google colleagues at the LLVM Developers’ Meeting.
The impression I got was that they seemed committed to SFrame as a viable solution without fully considering existing alternatives, with a determination to upstream it.
However, they did agree that if better solutions emerge, they would consider them - which I genuinely appreciate and view as a constructive approach.
However, you’re right that focusing on the organizational pressure doesn’t advance the technical discussion.
On tone and productive discussion: I’ll be mindful of how I frame concerns. I’d also hope we can maintain balanced standards — dismissing technical questions as “nitpicking” or “rabbit holes” doesn’t foster the technical discussion we need either. Let’s all focus on the substance.
The core issue is timeline pressure. Whether driven by organizational goals, user commitments, or other factors, there seems to be urgency to upstream SFrame despite acknowledged fundamental issues.
My concern is that this urgency is overriding the normal technical review process that would typically prevent upstreaming something we agree is architecturally flawed.
The post-processing alternative I proposed provides a path to gather real-world experience without committing LLVM to supporting a format that may need complete redesign. This addresses the urgency while preserving technical judgment.
My takeaway from the linux-perf-users discussion is that significant concerns about SFrame have emerged.
https://lore.kernel.org/linux-perf-users/CAN30aBGX+CuPmPGRjzpRT69pP0QJc_zBAr69RqnMUZ-OXF=t1A@mail.gmail.com/
With these discussions bringing visibility to alternative solutions like compact unwind formats and their efficiency characteristics, perf maintainers are likely to raise the bar for accepting any stack walking mechanism.
All of this challenges the maturity of the current format and implementation, favoring incubation rather than direct contribution to the main branch.