Project

General

Profile

Actions

Feature #5903

closed

Optimize st_table (take 2)

Added by funny_falcon (Yura Sokolov) about 12 years ago. Updated over 7 years ago.

Status:
Closed
Target version:
-
[ruby-core:42164]

Description

Given some of preparations to this patches already merged into ruby-trunk,
I suggest patches for improving st_table second time (first were #5789):

  1. Usage of packing for st_table of any kind, not only for numeric hashes.

Most of hashes, allocated during page render in Rails are smaller than 6 entries.
In fact, during rendering "Issues" page of Redmine, 40% of hashes not even grows
above 1 entry. They are small options hashes, passed to numerous helper methods.

This patch packs hashes upto 6 entries in a way like numeric hashes from trunk.
Also it pack hashes of size 0 and 1 into st_table inself, so that there is no
need to allocate any "bins" at all.

https://github.com/ruby/ruby/pull/84.patch
https://github.com/ruby/ruby/pull/84

  1. Usage of specialized pool for allocating st_table, st_table_entry structures
    and st_table.bins of smallest size (11)

Usage of specialized pool for this allocations give great speedup for hash creation.
Also it gives countable reduction of memory consumption.

https://github.com/ruby/ruby/pull/83.patch
https://github.com/ruby/ruby/pull/83

First patch gives little overhead for creating hashes bigger than 6 entries when applied alone.
But both patches combined are not slower than ruby-trunk for hashes of any size.

Performance testing is here https://gist.github.com/1626602


Related issues 1 (0 open1 closed)

Related to Ruby master - Feature #12142: Hash tables with open addressingClosedActions
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0