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

        Hide
        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
        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
        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
        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
        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
        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
          • Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: