[ruby-core:28937] Re: st.c: pool allocator for tables and entries

On Wed, Mar 24, 2010 at 07:43:56PM +0900, NARUSE, Yui wrote:
> (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.

FWIW, Nokogiri uses st.h.

-- 
Aaron Patterson
http://tenderlovemaking.com/