JRuby

JRuby startup time significantly slower than MRI

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Incomplete
  • Affects Version/s: JRuby 0.9.0, JRuby 0.9.1, JRuby 0.9.2, JRuby 0.9.8, JRuby 0.9.9, JRuby 1.0.0RC1, JRuby 1.0.0RC2, JRuby 1.0.0RC3, JRuby 1.0.0, JRuby 1.0.1, JRuby 1.0.2, JRuby 1.0.3, JRuby 1.1b1, JRuby 1.1RC1, JRuby 1.1RC2, JRuby 1.1RC3, JRuby 1.1, JRuby 1.1.1, JRuby 1.x+
  • Fix Version/s: None
  • Component/s: Performance
  • Labels:
    None
  • Environment:
    32-bit Linux and Windows Vista
  • Number of attachments :
    0

Description

Jruby startup time can take as much as a couple of seconds, compared with instantaneous startup time using MRI. For instance, on Linux with Jruby 1.1, simply invoking rake --version on a core 2 duo desktop got timed at 2.8 seconds, compared with .2 seconds using MRI rake. While insignifcant for web deployment, this slow startup time greatly affects the use of ruby as a general purpose scripting language.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

A command-line trick to be released in 1.1.2 will greatly improve startup time. For me, it's about 50% faster.

Show
Charles Oliver Nutter added a comment - A command-line trick to be released in 1.1.2 will greatly improve startup time. For me, it's about 50% faster.
Hide
Permalink
Sean Reque added a comment -

Startup times has definitely improved for recent versions, but it is still bad enough that i do not use jruby for normal development. There may be no easy way to fix this issue, but I at least want to report it so that the issue is known. Here are some sample startup times on my intel core 2 duo machine Ubuntu machine.

ruby --version: ~.5s
rake --version: ~1.5s
buildr --version: ~2.75s

The trend can be explained by the fact that rake runs on top of jruby and buildr in turn relies on rake. This seems to show that most of the .5 seconds startup time for ruby is not constant and does not armortize out for larger programs. Instead, the larger programs load many times more slowly.

Ruby's startup time has definitely improved from the time I first submitted this issue, but once one begins to run ruby programs of moderate size the startup time becomes unbearable. 3 seconds is too long to wait just for buildr to fire up, let alone do anything, especially when the task it will execute may take less than a second. The same issue applies to rake. Another example of the impact of this startup time is that if one has a syntax error in his or her build file, each edit/compile cycle will be at least 3 seconds. With MRI 1.8.7, buildr starts up in ~.275 seconds, or in 1/100 the time.

Show
Sean Reque added a comment - Startup times has definitely improved for recent versions, but it is still bad enough that i do not use jruby for normal development. There may be no easy way to fix this issue, but I at least want to report it so that the issue is known. Here are some sample startup times on my intel core 2 duo machine Ubuntu machine. ruby --version: ~.5s rake --version: ~1.5s buildr --version: ~2.75s The trend can be explained by the fact that rake runs on top of jruby and buildr in turn relies on rake. This seems to show that most of the .5 seconds startup time for ruby is not constant and does not armortize out for larger programs. Instead, the larger programs load many times more slowly. Ruby's startup time has definitely improved from the time I first submitted this issue, but once one begins to run ruby programs of moderate size the startup time becomes unbearable. 3 seconds is too long to wait just for buildr to fire up, let alone do anything, especially when the task it will execute may take less than a second. The same issue applies to rake. Another example of the impact of this startup time is that if one has a syntax error in his or her build file, each edit/compile cycle will be at least 3 seconds. With MRI 1.8.7, buildr starts up in ~.275 seconds, or in 1/100 the time.
Hide
Permalink
Franz Bettag added a comment -

jruby 1.3.0RC1 (ruby 1.8.6p287) (2009-05-11 6586) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_13) [amd64-java]

  1. time rake --version
    rake, version 0.8.4

real 0m9.711s
user 0m9.333s
sys 0m0.272s

  1. cat /proc/cpuinfo
    processor : 0
    vendor_id : GenuineIntel
    cpu family : 15
    model : 6
    model name : Intel(R) Xeon(TM) CPU 3.00GHz
    stepping : 4
    cpu MHz : 2992.500
    cache size : 2048 KB
Show
Franz Bettag added a comment - jruby 1.3.0RC1 (ruby 1.8.6p287) (2009-05-11 6586) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_13) [amd64-java] time rake --version rake, version 0.8.4 real 0m9.711s user 0m9.333s sys 0m0.272s cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 6 model name : Intel(R) Xeon(TM) CPU 3.00GHz stepping : 4 cpu MHz : 2992.500 cache size : 2048 KB
Hide
Permalink
Charles Oliver Nutter added a comment -

Ouch, 9s.

A substantial part of the startup time right now is because so much code runs in RubyGems at startup. Because JRuby's cold, code run early in a cycle is slowest, which means before the application you're trying to run even does any work rubygems has taken away agility.

Two efforts are converging to help this:

  1. A patch to RubyGems to reduce the execution cost of starting up
  2. Nailgun revival in 1.3 to move it toward being a feasible tool

The latter will reduce startup times nearly to MRI speeds, but needs work (and we'd love to have people help).

Show
Charles Oliver Nutter added a comment - Ouch, 9s. A substantial part of the startup time right now is because so much code runs in RubyGems at startup. Because JRuby's cold, code run early in a cycle is slowest, which means before the application you're trying to run even does any work rubygems has taken away agility. Two efforts are converging to help this: A patch to RubyGems to reduce the execution cost of starting up Nailgun revival in 1.3 to move it toward being a feasible tool The latter will reduce startup times nearly to MRI speeds, but needs work (and we'd love to have people help).
Hide
Permalink
Charles Oliver Nutter added a comment -

I've merged in the Nailgun work, so it will be in 1.3. It still needs work to be rock-solid, but here's a sample:

~/projects/jruby ➔ cd tool/nailgun/ ; make ; cd -
Building ng client.  To build a Windows binary, type 'make ng.exe'
gcc -Wall -pedantic -s -O3 -o ng src/c/ng.c
ld warning: option -s is obsolete and being ignored
/Users/headius/projects/jruby

~/projects/jruby ➔ jruby --ng-server
NGServer started on all interfaces, port 2113.
^Z
[1]+  Stopped                 jruby --ng-server

~/projects/jruby ➔ bg
[1]+ jruby --ng-server &

~/projects/jruby ➔ jruby --ng -e "puts 1"
1

~/projects/jruby ➔ time jruby -e "puts 1"
1

real	0m0.609s
user	0m0.482s
sys	0m0.119s

~/projects/jruby ➔ time jruby --ng -e "puts 1"
1

real	0m0.073s
user	0m0.010s
sys	0m0.018s
Show
Charles Oliver Nutter added a comment - I've merged in the Nailgun work, so it will be in 1.3. It still needs work to be rock-solid, but here's a sample: ~/projects/jruby ➔ cd tool/nailgun/ ; make ; cd - Building ng client. To build a Windows binary, type 'make ng.exe' gcc -Wall -pedantic -s -O3 -o ng src/c/ng.c ld warning: option -s is obsolete and being ignored /Users/headius/projects/jruby ~/projects/jruby ➔ jruby --ng-server NGServer started on all interfaces, port 2113. ^Z [1]+ Stopped jruby --ng-server ~/projects/jruby ➔ bg [1]+ jruby --ng-server & ~/projects/jruby ➔ jruby --ng -e "puts 1" 1 ~/projects/jruby ➔ time jruby -e "puts 1" 1 real 0m0.609s user 0m0.482s sys 0m0.119s ~/projects/jruby ➔ time jruby --ng -e "puts 1" 1 real 0m0.073s user 0m0.010s sys 0m0.018s
Hide
Permalink
Charles Oliver Nutter added a comment -

Open-ended startup time issue. Resolving as incomplete; we're well aware of the problem.

Show
Charles Oliver Nutter added a comment - Open-ended startup time issue. Resolving as incomplete; we're well aware of the problem.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Sean Reque
Vote (1)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: