The Sync Heap: Delete First, Ask Questions Later
Summary
The paper introduces the sync heap, a novel data structure that decouples deletion from revealing the deleted element, enabling constant amortized time for insertions and deletions under limited inspections, and improving a textbook scheduling problem from O(n log n) to O(n).
View Cached Full Text
Cached at: 08/25/26, 05:45 PM
# The Sync Heap: Delete First, Ask Questions Later
Source: [https://arxiv.org/abs/2608.07134](https://arxiv.org/abs/2608.07134)
[View PDF](https://arxiv.org/pdf/2608.07134)
> Abstract:Heaps \(priority queues\) are among the best\-studied data structures in computer science\. In this paper, we critically revisit the textbook assumption that in the comparison model at least one of the two standard heap operations of inserting an element and deleting the minimum must take logarithmic time\. By decoupling the deletion itself from the act of revealing the identity of the deleted element to the user, we avoid the sorting barrier and obtain a novel trade\-off between the complexities of heap operations\. This shows that the logarithmic barrier is not inherently the cost of deleting the minimum but rather the information cost of immediately learning which element was deleted\. In the special case when the user inspects the heap state only constantly many times, we show that both insertions and deletions can be supported in constant amortized time\. As an application, this yields a runtime improvement from $\\mathcal\{O\}\(n \\log n\)$ to the optimal $\\mathcal\{O\}\(n\)$ for a textbook unit\-time scheduling problem\. We obtain our results by designing a new data structure, the sync heap, which gains speed by rearranging and compacting its operations until queries force it to synchronize and reveal its state\. As a key component, we use the soft heap introduced by Chazelle as part of his minimum spanning tree algorithm\. Our data structure is simple, comparison\-based, and deterministic, and our results are asymptotically optimal\.
## Submission history
From: Egor Gorbachev \[[view email](https://arxiv.org/show-email/205aaaa6/2608.07134)\] **\[v1\]**Fri, 7 Aug 2026 11:53:20 UTC \(35 KB\)Similar Articles
Why don’t we allow stacks to be sparse, instead of forcing them to be contiguous?
The article discusses why stacks are made contiguous in memory instead of sparse, highlighting security risks such as Stack Clash and implementation complexities in exception handling.
The Double Headed Stack Allocator
A technical blog post explaining the double headed (bump) stack allocator, a classic fast memory allocation trick born from game animation programming at Surreal Software, where allocation is just an integer addition and deallocation resets the top-of-stack pointer.
The Limits of Generalized Sync: ATaxonomy of Architectures, Trade‑offs, and Decision Factors
This thesis from Aalto University presents a taxonomy of synchronization architectures, analyzing trade-offs and decision factors to guide the design of generalized sync engines.
Dostoevsky: Better Space-Time Trade-Offs for LSM-Tree Based Key-Value Stores via Adaptive Removal of Superfluous Merging
This paper presents Dostoevsky, a system that improves the space-time trade-offs of LSM-tree based key-value stores by adaptively removing superfluous merging during compaction, yielding better performance than existing compaction strategies.
Premature Optimization is Fun Sometimes
A blog post exploring the optimization of a ring buffer data structure for storing ping timestamps, discussing tagged unions, bitfields, and struct padding to reduce memory footprint.