<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>RecSplit: Minimal Perfect Hashing via Recursive Splitting · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1910.06416/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1910.06416/feed.xml" rel="self" type="application/rss+xml" /><item><title>RecSplit: Minimal Perfect Hashing via Recursive Splitting — mentioned by thomasmg</title><link>https://news.ycombinator.com/item?id=43284484</link><guid isPermaLink="false">urn:hackerpapers:mention:1910.06416:43284484</guid><pubDate>Thu, 06 Mar 2025 19:58:15 GMT</pubDate><description>&lt;p&gt;For Java, C++, and Rust there is also https://sux.di.unimi.it/ maintained by Sebastiano Vigna, a professor from Italy. Together with his student (I also helped a bit), he wrote a paper about RecSplit, a minimal perfect hash function (MPHF) algorithm I have invented: https://arxiv.org/abs/1910.06416 - that algorithm uses around 1.56 bits per key. But it is quite slow. In January 2020 I presented the paper at a conference, that was right before the pandemic. The algorithm with the least memory usage (and much faster as well) is now Consensus-RecSplit: https://arxiv.org/abs/2502.05613 - it can…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1910.06416/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item><item><title>RecSplit: Minimal Perfect Hashing via Recursive Splitting — HN submission</title><link>https://news.ycombinator.com/item?id=25569004</link><guid isPermaLink="false">urn:hackerpapers:submission:1910.06416:25569004</guid><pubDate>Tue, 29 Dec 2020 12:11:19 GMT</pubDate><description>&lt;p&gt;RecSplit: Minimal Perfect Hashing via Recursive Splitting&lt;/p&gt;&lt;p&gt;&lt;/p&gt;&lt;p&gt;2 points; 0 discussion replies on HN. &lt;a href="https://hackerpaper.kaipfister.de/p/1910.06416/"&gt;Paper and source history&lt;/a&gt;. A submission is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item><item><title>RecSplit: Minimal Perfect Hashing via Recursive Splitting — HN submission</title><link>https://news.ycombinator.com/item?id=22613305</link><guid isPermaLink="false">urn:hackerpapers:submission:1910.06416:22613305</guid><pubDate>Wed, 18 Mar 2020 03:22:43 GMT</pubDate><description>&lt;p&gt;RecSplit: Minimal Perfect Hashing via Recursive Splitting (2019)&lt;/p&gt;&lt;p&gt;&lt;/p&gt;&lt;p&gt;4 points; 0 discussion replies on HN. &lt;a href="https://hackerpaper.kaipfister.de/p/1910.06416/"&gt;Paper and source history&lt;/a&gt;. A submission is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item><item><title>RecSplit: Minimal Perfect Hashing via Recursive Splitting — mentioned by thomasmg</title><link>https://news.ycombinator.com/item?id=21842750</link><guid isPermaLink="false">urn:hackerpapers:mention:1910.06416:21842750</guid><pubDate>Fri, 20 Dec 2019 09:21:51 GMT</pubDate><description>&lt;p&gt;Interesting idea! Elias-Fano monotone sequences unfortunately do need a bit more space than just a list of Rice codes. What is possible, without having to increase the space usage, is to re-arrange the Rice codes in each bucket, so that all variable parts come first, and the fixed parts at the end. That way, lookup speed would be much, much faster for large buckets. We used this for RecSplit: https://arxiv.org/abs/1910.06416 I will try that out for GCS as well!&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1910.06416/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item></channel></rss>
