Shrinking Ruby Hashes

The article measures memory consumption with ObjectSpace.memsize_of, showing that an empty Hash occupies 160 bytes while a comparable Struct uses only 40 bytes. As the number of elements grows, the Hash remains two to four times larger than the Struct across the tested range. This disparity highlights a steady source of allocator pressure in applications that create many short-lived Hashes during request processing.

A key historical shift discussed is the move to an open-addressing hash table, which altered the underlying C structure. The header struct grew from 48 bytes in the earlier design to 56 bytes after the change, increasing the baseline memory cost of every Hash instance regardless of its payload size. This header growth is presented as a major contributor to the observed overhead.

For very small Hashes (zero to eight entries) Ruby does not allocate a full hash table; instead it uses a packed entry layout that stores elements directly in the header space. Consequently, the memory advantage of switching to a more compact representation is limited for these sizes, and any optimization must consider both the packed and table-based paths.

Adopting a slimmer Hash would require modifications to the Ruby interpreter’s core data structures and possibly to the garbage collector’s handling of these objects. Such changes could affect lookup performance, introduce incompatibilities with C extensions that rely on the current layout, and necessitate extensive testing across Ruby versions.

The benefits of reducing the header size diminish for large Hashes where the memory consumed by the bins array dominates total usage. Any shrink-effort must preserve the collision-resolution properties of open addressing, so the approach stops working effectively once the number of bins becomes the primary memory consumer.