For what it's worth, we do intend to look into improving the startup time before 1.6.0 final release. The last-minute change to include RubyGems instead of doing "gem_prelude" like Ruby 1.9.2 added some time, and the extra libraries being loaded also adds time.
On Sat, Jan 8, 2011 at 1:02 AM, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com> wrote: > On 08-01-2011 00:12, Hirotsugu Asari wrote: >> >> On Jan 7, 2011, at 8:36 PM, Rodrigo Rosenfeld Rosas wrote: >> >>> It seems a lot is needed for running a simple ruby script with 1.9 while >>> much less is required by 1.8. >>> >>> Charles Nutter has talked recently about some tips to speed jruby startup >>> time. One of them is "export JAVA_OPTS='-d32'", but I get this on Linux: >>> >>> Running a 32-bit JVM is not supported on this platform. >> >> It probably means that you don't have a 32-bit JVM installed. >> >> http://java.com/en/download/manual.jsp You'll want the second one in the >> Linux list. >> >>> Is there any other tip that I could use for a 64-bit JVM on Linux to >>> speed up the startup time? >> >> Having said that, if the 1.9 start-up time is driven by disk I/O for >> reading lots of files (which I suspect is the case), the changing JVM won't >> help you much. >> >> [system]:~ $ time jruby -v -J-Djruby.debug.loadService.timing=true --1.9 >> -e 'p 1' >> jruby 1.6.0.dev (ruby 1.9.2 trunk 136) (2011-01-07 19f7456) (Java >> HotSpot(TM) 64-Bit Server VM 1.6.0_22) [darwin-x86_64-java] >> -> thread.jar >> <- thread.jar - 5ms >> -> rbconfig >> <- rbconfig - 151ms >> -> rubygems/defaults/operating_system >> <- rubygems/defaults/operating_system - 15ms >> -> enumerator >> -> generator_internal >> -> thread >> <- thread - 0ms >> <- generator_internal - 83ms >> <- enumerator - 112ms >> 1 >> >> real 0m1.660s >> user 0m1.502s >> sys 0m0.152s >> >> [system]:~ $ JAVA_OPTS=-d32 time jruby -v >> -J-Djruby.debug.loadService.timing=true --1.9 -e 'p 1' >> jruby 1.6.0.dev (ruby 1.9.2 trunk 136) (2011-01-07 19f7456) (Java >> HotSpot(TM) Client VM 1.6.0_22) [darwin-i386-java] >> -> thread.jar >> <- thread.jar - 7ms >> -> rbconfig >> <- rbconfig - 204ms >> -> rubygems/defaults/operating_system >> <- rubygems/defaults/operating_system - 6ms >> -> enumerator >> -> generator_internal >> -> thread >> <- thread - 0ms >> <- generator_internal - 25ms >> <- enumerator - 46ms >> 1 >> 1.45 real 1.06 user 0.14 sys >> >> > Yes, I guess the problem with jars is that the OS can't cache them like they > do with dynamic libraries and they will be loaded from disk each time so > that I would need a super fast HD for getting the program to start faster :( > > Thank you for your time, > > Rodrigo > > --------------------------------------------------------------------- > 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
