[ruby-core:43591] [ruby-trunk - Feature #5903] Optimize st_table (take 2)

Issue #5903 has been updated by funny_falcon (Yura Sokolov).


As far this ticket not closed, I'll post hash related patch here:

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

1. remove some unused code from st.c and hash.c
2. change rb_hash_modify to rb_hash_modify_check when st_table allocation is not necessary
3. move part of safe iteration logic to st.c to make it clearer
   This is arguable change, cause it clearly do not have positive impact on performance,
   but `make check` consumes 592.2 second before this change and 595.4 after - less than 1 percent,
   so that I suppose, difference is negligible.
4. introduce st_shift to optimize Hash#shift


----------------------------------------
Feature #5903: Optimize st_table (take 2)
https://bugs.ruby-lang.org/issues/5903#change-25087

Author: funny_falcon (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/