redblack benchmark slower than it should be
-------------------------------------------

                 Key: JRUBY-5428
                 URL: http://jira.codehaus.org/browse/JRUBY-5428
             Project: JRuby
          Issue Type: Bug
          Components: Performance
    Affects Versions: JRuby 1.6RC1
            Reporter: Charles Oliver Nutter


There's probably a lot of things that could be improved on the redblack 
benchmark that's been floating around.

gist/repo: git://gist.github.com/44301.git

numbers:

{noformat}
~/projects/gist-44301 ➔ jruby -v --server bm1.rb
jruby 1.6.0.RC1 (ruby 1.8.7 patchlevel 330) (2011-01-26 80ab30a) (Java 
HotSpot(TM) Server VM 1.6.0_22) [darwin-i386-java]
./red_black_tree.rb:37 warning: instance variable @instance not initialized
5.216
2.908
2.943
2.913
3.051

~/projects/gist-44301 ➔ jruby --1.9 -v --server bm1.rb
jruby 1.6.0.RC1 (ruby 1.9.2 patchlevel 136) (2011-01-26 80ab30a) (Java 
HotSpot(TM) Server VM 1.6.0_22) [darwin-i386-java]
/Users/headius/projects/gist-44301/red_black_tree.rb:37 warning: instance 
variable @instance not initialized
5.799
3.627
3.566
3.664
3.585
{noformat}

The 1.9 numbers are discussed in JRUBY-5427, but both numbers could probably be 
improved a lot. Rubinius numbers for this benchmark (which is admittedly very 
numeric and Ruby object-heavy) are in the neighborhood of 1s, so we're at best 
about 3x slower.

Top offenders from an allocation profile (for just the first two iterations) 
show a ton of Object[] being created (for ivar tables) along with the usual 
RubyFixnum objects and many, many IRubyObject[]:

{noformat}
          percent          live          alloc'ed  stack class
 rank   self  accum     bytes objs     bytes  objs trace name
    1 33.78% 33.78%  43668384 909758 103320192 2152504 302748 
org.jruby.RubyFixnum
    2 12.59% 46.38%  16275392 254303  22672256 354254 314598 java.lang.Object[]
    3  9.98% 56.35%  12896800 403025  28579072 893096 314705 
org.jruby.runtime.builtin.IRubyObject[]
    4  7.87% 64.22%  10172520 254313  14172560 354314 311802 
org.jruby.RubyObject
    5  6.33% 70.56%   8187136 255848  32000064 1000002 313755 
org.jruby.runtime.builtin.IRubyObject[]
    6  3.82% 74.38%   4937344 154292  11336064 354252 314707 
org.jruby.runtime.builtin.IRubyObject[]
    7  3.74% 78.12%   4839552    8  11362632    91 312361 
org.jruby.runtime.builtin.IRubyObject[]
    8  2.48% 80.60%   3201344 100042   6400736 200023 314747 
org.jruby.runtime.builtin.IRubyObject[]
    9  2.48% 83.07%   3200832 100026   6401920 200060 313772 
org.jruby.runtime.builtin.IRubyObject[]
   10  2.48% 85.55%   3200000 100000   6398400 199950 314745 
org.jruby.runtime.builtin.IRubyObject[]
   11  2.48% 88.03%   3199904 99997   8001472 250046 314746 
org.jruby.runtime.builtin.IRubyObject[]
   12  2.28% 90.31%   2948024 46003   2948024 46003 300000 java.lang.Object[]
   13  1.41% 91.72%   1827880 45697   1827880 45697 300000 org.jruby.RubyObject
   14  1.34% 93.06%   1737728 54304   8137696 254303 314751 
org.jruby.runtime.builtin.IRubyObject[]
   15  0.48% 93.55%    625968 9585    625968  9585 300000 char[]
   16  0.30% 93.85%    383656 9574    383656  9574 300000 java.lang.String
   17  0.11% 93.95%    140240 3506    166320  4158 308716 
org.jruby.runtime.callsite.NormalCachingCallSite
   18  0.10% 94.05%    125376 3918    435584 13612 308555 
org.jruby.lexer.yacc.SimpleSourcePosition
   19  0.09% 94.14%    115360 2884    142120  3553 308693 
org.jruby.ast.ArrayNode
   20  0.09% 94.23%    115360 2884    142120  3553 308696 java.util.ArrayList
{noformat}

In fact, the allocation numbers are totally dominated by fixnums, Object[], and 
IRubyObject[].

Some of the IRubyObject[] are due to blocks not being arity split. Some are due 
to dispatches going through array or varargs paths within JRuby.

I'm not sure whether the allocation overhead is the primary bottleneck, but it 
seems very likely at this point given the massive number of objects being 
created and thrown away.

We should explore this benchmark in detail and see what we can improve.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to