Static search trees: 40x faster than binary search (2024)
lalitmaganti
82 points
3 comments
July 17, 2026
Related Discussions
Found 5 related stories in 319.7ms across 14,015 title embeddings via pgvector HNSW
- 6× faster binary search: from compiled code to mechanical sympathy enz · 15 pts · July 12, 2026 · 59% similar
- B-trees and database indexes (2024) tosh · 97 pts · April 13, 2026 · 54% similar
- You can beat the binary search signa11 · 21 pts · April 30, 2026 · 54% similar
- SereneDB's C++ search engine is the fastest on search benchmarks gnusi · 31 pts · March 19, 2026 · 49% similar
- The future of code search is not regex – 100x faster than ripgrep neogoose · 14 pts · April 02, 2026 · 48% similar
Discussion Highlights (3 comments)
jas-
Thanks for sharing this
stevefan1999
My first instinct is https://en.wikipedia.org/wiki/Van_Emde_Boas_tree Not sure why
kazinator
> The main benefit of the Eytzinger layout is that all values needed for the first steps of the binary search are close together, so they can be cached efficiently: we put the root at index 1 and the two children of the node at index i are at 2i and 2i + 1. This is exactly what is done in good old binary heaps; though binary heaps do not maintain a balanced binary tree, only the property that key(parent) < key(left_child) and key(parent) < key(right_child) . Binary heaps don't support efficient search for a particular key. I don't remember ever reading a description of binary heaps which mentioned Eytzinger. This is because the layout for binary heaps was discovered without knowledge of Eytzinger. It may have been Knuth who discovered Eytzinger and made the connection? It's quite obvious that this layout is good for caching. The first few layers of the tree will all fit into a single VM page, the nodes closest to the root into one cache line. Then the subsequent layers are similarly packed in order. Let's say that k layers of the tree fit into page. If the search path from root to leaf is 3k , it should touch only three pages, right?