From: "NARUSE, Yui" <naruse@...>
Date: 2010-03-24T19:43:56+09:00
Subject: [ruby-core:28923] Re: st.c: pool allocator for tables and entries

(2010/03/22 17:05), Eric Wong wrote:
> Hi all,
>
> I started playing around with pool allocator for Ruby 1.9 for hashes.  I
> cooked this up for an app that generates lots of Hashes.  After getting
> some performance improvements from tweaking constants inside gc.c for
> the app and using bsdmalloc[1], I still got a ~10% runtime reduction
> with this small change (for one particular app).
>
> This assumes st.c is only called inside GVL, and GVL == GIL which is
> true these days in 1.9.1 and trunk.
>
> The only other downside is that memory used for each type of struct
> cannot be used anything else, nor released back to the OS (though some
> malloc implementations don't do this anyways).
>
> I've sized both of the pools conservatively (8K) for now.
>
> Further testing and benchmarks results on different apps and comments
> would be greatly appreciated.
>
> This patch should apply cleanly to trunk, and works with 1.9.1, too.
>
> [1] I used bsdmalloc from here: git://github.com/ice799/bsdmalloc

st.c is used not only from GC, but by other extensions.

I don't know whether st.h is public API or not.
But if a library uses st_table in multi thread way,
it will break when st_table become thread unsafe.

-- 
NARUSE, Yui  <naruse@airemix.jp>