From: Yura Sokolov <funny.falcon@...>
Date: 2012-01-31T14:08:32+09:00
Subject: [ruby-core:42282] [ruby-trunk - Feature #5903] Optimize st_table (take 2)


Issue #5903 has been updated by Yura Sokolov.


Nobuyoshi Nakada wrote:
> What's "_black_magick"?

On my computer, pool allocator work by 1% faster when I keep those two assignment to this "magic" field.

May be it is a case of my computer, cause when I remove `heaps_freed`  from gc.c (`objspace->heap.freed` http://bugs.ruby-lang.org/projects/ruby-trunk/repository/entry/gc.c#L412 ), it start to work slower too.
But it is not ever assigned (cause it is initialized with zero, and `last < heaps_freed` is never true http://bugs.ruby-lang.org/projects/ruby-trunk/repository/entry/gc.c#L2170 )
----------------------------------------
Feature #5903: Optimize st_table (take 2)
https://bugs.ruby-lang.org/issues/5903

Author: Yura Sokolov
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 2.0.0


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

2) 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


-- 
http://bugs.ruby-lang.org/