[ruby-core:20825] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use

Hi, Brent:

   I have test MBARI patch on JavaEye.com (http://www.javaeye.com) , that i=
s
a chinese software development community website which has 200,000 members
and 800,00 pageviews per day. JavaEye is written by Ruby on Rails and
running with lighttpd/fastcgi mode. The server environment: AMD64 machine,
SuSE Linux x86-64, ruby 1.8.7-p72 and Rails 2.1.2.

   I test Rails app performance and memory usage with 4 ruby implements:=20

   1. ruby MRI  1.8.7-p72

   2. ruby 1.8.7-p72 with Railsbench GC patch and set GC variables below:
          RUBY_HEAP_MIN_SLOTS=3D600000
          RUBY_HEAP_SLOTS_INCREMENT=3D600000
          RUBY_HEAP_FREE_MIN=3D100000
          RUBY_GC_MALLOC_LIMIT=3D60000000
=20
   3. ruby 1.8.7-p72 with MBARI patch.

   4. ruby 1.8.7-p72 with MBARI patch but I modified GC variables in gc.c
same as above.


   Test one: Simple Rails app

    I create a simple rails app to test rails routes and template rendering=
:

 ab -c 1 -n 1000 http://localhost:3000/test/index

ruby version                          performance      memory=20
-----------------------------------------------------
ruby                                    106 request/s     39MB
ruby GC patch                       125 request/s     60MB
ruby MBARI patch                  160 request/s     35MB
ruby MBARI merge GC patch    173 request/s      60MB

 Test One Summary: MBARI patch save a little memory than MRI but improve
rails performance significantly.

   Test two: Real Rails website test
  =20
    I select two typical page on JavaEye.com to benchmark:

    Page 1 : http://robbin.javaeye.com/=20

ab -c 1 -n 100 http://robbin.joinnet.cn/

ruby version                 performance      memory=20
-----------------------------------------------------
ruby                                  1.69 request/s    136MB
ruby GC patch                     2.81 request/s    179MB
ruby MBARI patch                1.96 request/s    103MB
ruby MBARI merge GC patch   2.90 request/s    158MB

     Page 2: http://robbin.joinnet.cn/blog/283992

ruby version                        performance      memory=20
-----------------------------------------------------
ruby                                  2.20 request/s    136MB
ruby GC patch                     3.61 request/s    179MB
ruby MBARI patch                2.47 request/s    103MB
ruby MBARI merge GC patch  3.73 request/s    158MB

Test Two Summary:=20

   1. MBARI patch not only save a lot of memory than MRI but also improve
rails performance about 13%
   2. MBARI merge with Railsbench GC patch win others with the highest rail=
s
performance and save some memory than Railsbench GC patch.

 My suggest:

    1. MBARI patch has some uncompatible with complicated Regexp. for
example, I met this  error: premature end of regular expression: /0=C3=A3k
\000\000\000\000x/  On line #12 of blog/index/_blog.rhtml

    2. I wish MBARI merge Railsbench GC patch, because Railsbench GC patch
has a lot of rails performance improvement on JavaEye.com website.

    3. I expect MBARI merge into ruby trunk :)



Brent Roman wrote:
>=20
> I've finally put together the promised set of patches against version
> 1.8.7-p72 and posted them at:
>=20
> http://sites.google.com/site/brentsrubypatches
>=20
> From that page:
>=20
> Aside from bug fixes, the primary goal of these patches is to reduce the
> memory consumption of the 1.8 series Ruby interpreters.  Happily, these
> same techniques tend also to increase the speed of most applications, but
> speed increase was not my primary concern.=20
>=20
> Each of the six patches below (mbari1-6) fixes a specific problem with or
> optimizes some facet of the Ruby interpreter.  The patches were intended
> to be applied in order, starting with official interpreter release
> 1.8.7-patchlevel72 from ruby-lang.org.  However, you may be able to apply
> only a subset of them if you don't want a particular feature or
> optimization.
>=20
> Until more people test them, this must all be treated as alpha quality
> software. ...
>=20
> My development environment today is 32-bit Intel x86 Linux compiling with
> gcc version 4.3.2.  I've tried to keep these patches portable to other
> platforms, but will make no such claims until others have tested them
> there.  If you test these under MS-Windows, I'll be interested and try to
> be helpful, but I won't be able to verify your results.
>=20
> Please post any bugs, flames, benchmark results, requests for improvement=
,
> etc. to the ruby-core mailing list by replying to this message.
>=20

--=20
View this message in context: http://www.nabble.com/-ruby-core%3A19846---Bu=
g--744--memory-leak-in-callcc--tp20447794p21140287.html
Sent from the ruby-core mailing list archive at Nabble.com.