Forum: JRuby jruby trunk is *way* faster than 1.1.6

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Chuck R. (Guest)
on 2009-03-20 16:07
(Received via mailing list)
I ran one of my private benchmarks which tests the performance of the
json-jruby gem (latest rev). I have pastied the results here:

http://pastie.org/421969

The benchmark itself is available here:

http://pastie.org/421974


 From a 10,000 foot view, the changes to jruby since 1.1.6 improved
the benchmark results by around 20%. Using the --server and --fast
switches gave an *overall* improvement of around 45%. The tests were
run with jruby 1.1.6 release and the jruby-trunk as of March 19 2009.

A few weeks ago I ran these tests under MRI (with the C json gem) but
I didn't save the results. Suffice it to say that jruby destroyed MRI
in that test by around 35% (though memory usage was much higher under
jruby, like 2GB (jruby) versus 500MB (MRI)).

Jruby is getting seriously fast for *my* uses. I tested this on the 32-
bit Java5 VM under OSX Intel. I know from prior benchmarks that
running the 64-bit Java6 VM provides an absolute improvement of around
another 10% with server mode boosting that to 15%. YMMV.

Many many many thanks to Charles, Tom, Nick and the cast of hundreds
who have been making such steady progress on our favorite ruby
implementation!

cr


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

    http://xircles.codehaus.org/manage_email
Charles Oliver N. (Guest)
on 2009-03-21 01:21
(Received via mailing list)
Those are great numbers! Can you also do a run of the numbers with
--server under JRuby 1.1.6? Then we can compare apples to apples all the
way through.

I'm hoping for 1.3 to make --fast a real production option, and we also
have a bunch of optimization ideas that may finally put JRuby way out in
front as far as Ruby performance goes. It would be nice to convincingly
"win" the benchmarks game so we can put that to bed for a while.

Chuck R. wrote:
>  From a 10,000 foot view, the changes to jruby since 1.1.6 improved the
> 32-bit Java5 VM under OSX Intel. I know from prior benchmarks that
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


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

    http://xircles.codehaus.org/manage_email
Chuck R. (Guest)
on 2009-03-21 13:30
(Received via mailing list)
I'll do another run through on Monday with --server and jruby 1.1.6.
For kicks, I'll also run everything under Java6 64-bit since running
this stuff is pretty much fire-and-forget anyway.

I'll post 'em Tuesday.

cr

On Mar 20, 2009, at 6:21 PM, Charles Oliver N. wrote:

> Chuck R. wrote:
>> A few weeks ago I ran these tests under MRI (with the C json gem)
>> but I didn't save the results. Suffice it to say that jruby
>> destroyed MRI in that test by around 35% (though memory usage was
>> much higher under jruby, like 2GB (jruby) versus 500MB (MRI)).
>> Jruby is getting seriously fast for *my* uses. I tested this on the
>> 32-bit Java5 VM under OSX Intel. I know from prior benchmarks that
>> running the 64-bit Java6 VM provides an absolute improvement of
>> around another 10% with server mode boosting that to 15%. YMMV.
>> Many many many thanks to Charles, Tom, Nick and the cast of
>> hundreds who have been making such steady progress on our favorite
>> ruby implementation!

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

    http://xircles.codehaus.org/manage_email
Charles Oliver N. (Guest)
on 2009-03-21 19:31
(Received via mailing list)
Chuck R. wrote:
> Jruby is getting seriously fast for *my* uses. I tested this on the
> 32-bit Java5 VM under OSX Intel. I know from prior benchmarks that
> running the 64-bit Java6 VM provides an absolute improvement of around
> another 10% with server mode boosting that to 15%. YMMV.

It's probably worth mentioning that we also did no major architectural
work to improve performance in 1.2. Almost all improvements were solely
from "cleanup" work that just reduced overhead of the code we already
had. The exception would be --fast, which has existed for a while, but
which had a number of major changes to make it "safer" for real Ruby
code.

I'm planning to do some larger architectural changes for 1.3 that will
hopefully produce much more significant performance boosts across the
board.

- Charlie

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

    http://xircles.codehaus.org/manage_email
Chuck R. (Guest)
on 2009-03-24 14:48
(Received via mailing list)
On Mar 21, 2009, at 6:29 AM, Chuck R. wrote:

>> Those are great numbers! Can you also do a run of the numbers with
>> --server under JRuby 1.1.6? Then we can compare apples to apples
>> all the way through.
>>
>> I'm hoping for 1.3 to make --fast a real production option, and we
>> also have a bunch of optimization ideas that may finally put JRuby
>> way out in front as far as Ruby performance goes. It would be nice
>> to convincingly "win" the benchmarks game so we can put that to bed
>> for a while.
>>



I reran the benchmarks using the 64-bit Java6 VM under OSX 10.5.6.
Here are the results in separate pasties so you can put the windows
side-by-side for comparison.

JRuby 1.1.6 (with and without --server)
http://pastie.org/424711


JRuby trunk (20090319)
http://pastie.org/424717  (no switches && --server + --fast)

http://pastie.org/425329 (just the --server switch)

Clearly the --server switch improves overall performance. The --fast
switch also gives a nice boost on top of it. If you can run your code
with that switch and it remains stable, go for it.

It's hard to believe that these performance improvements are all from
a little bit of code cleanup. Whatever the reality, jruby is wicked
fast.

cr


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

    http://xircles.codehaus.org/manage_email
This topic is locked and can not be replied to.