Timing Wheels
Posted2 months agoActiveabout 2 months ago
pncnmnp.github.ioTechstory
calmmixed
Debate
40/100
Data StructuresAlgorithm DesignTiming Wheels
Key topics
Data Structures
Algorithm Design
Timing Wheels
The article discusses the concept of timing wheels, a data structure for efficient timer management, with commenters debating its usefulness and comparing it to alternative data structures like priority queues.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
4d
Peak period
1
96-108h
Avg / period
1
Key moments
- 01Story posted
Nov 1, 2025 at 12:00 PM EDT
2 months ago
Step 01 - 02First comment
Nov 5, 2025 at 10:58 PM EST
4d after posting
Step 02 - 03Peak activity
1 comments in 96-108h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 6, 2025 at 2:08 PM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45782702Type: storyLast synced: 11/20/2025, 1:30:03 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
This is a useful data structure for its niche where accuracy doesn't matter and most events will be canceled, but I would not use this article to learn about it.
This does remind me of some thoughts on what a timer API should look like - there needs to be a distinction between "fire-and-forget so never cancel", "owned but cancellation is rare", "owned and cancellation is common". I've almost exclusively used the first two; for rare cancellations you can rely a lot on amortized constant overhead, or use bubbling, or use precise tracked cancellation.
... this is one case when I utilized C++ nontrivial move constructors to their fullest extent, something which Rust chooses to make utterly impossible.
I have described it in the "Timer Modules" section:
> A natural iteration of this approach is to store timers in an ordered list (also known as timer queues). In this scheme, instead of storing the time interval, an absolute timestamp is stored. The timer identifier and its corresponding timestamp that expires the earliest is stored at the head of the queue. Similarly, the second earliest timer is stored after the earliest, and so on, in ascending order. After every unit, only the head of the queue is compared with the current timestamp. If the timer has expired, we dequeue the list and compare the next element. We repeat this until all the expired timers have been dequeued, and we run their expiry processing routines.
And then, I go on to talk about its runtime.
Truth be told, this is a chapter for my book on data structures and algorithms that I think are interesting and obscure enough that not many people talk about them. Its goal is not widespread practicality, but rather a fun deep dive into some topics.