script/console execs irb, causes double process-launch and limits other impls

I just noticed that the script/console script also requires config/boot, which means that the exec is also causing a second load of Rails and the application. So this fix would potentially improve the startup time of the console on all implementations.

Fix for the bug iffy mentions here: http://github.com/rails/rails/co...

(from [04fdb6eccb3a49b26bdbf779031f427da23a8bb4]) Revert "Speed up script/console by launching IRB directly."

[#2104 script/console execs irb, causes double process-launch and limits other impls state:open]

This reverts commit 3b169cd693f45911ee71e26708fb9267811c8d83. http://github.com/rails/rails/co...

I noticed the whole commit was reverted, even though a fix was proposed. Is there something else wrong with the change?

The fix doesn't work. The environment has already been loaded by boot.rb at that point.

Umm, my fix does work, it moves the command line arg parsing into railties/bin/console before the boot is loaded.

Sorry Jason, I misread your patch.

Couldn't the new console behavior be added in a different file, and new script/console require that one instead? Then the old behavior would still work in existing apps and newly-generated apps would get the new behavior, starting up fastest, etc.

I'd really like to see this get into 2.3.

ok. so not to be a whiner without a solution, i've patched my rails to do the following:
1) symlink /usr/local/ruby/bin -> /usr/local/ruby//bin
2) replaced all /usr/bin/env ruby sherbangs with /usr/local/ruby/bin/ruby
3) added RUBY_PATH = '/usr/local/ruby/bin' to boot.rb
4) changed console.rb and other references to RUBY_PLATFORM to say irb = "#{RUBY_PATH}/irb" || RUBY_PLATFORM ...

not sure if this is generalizeable to other systems, but it seems to take care of most of my issues and allows me to switch ruby versions with just the symlink. i kept the symlink off the usual paths so it doesn't screw with my production 1.8 gems/paths. at the very least this will give me experience maintaining my own rails patches via git clone/rebase. :)

sorry looks like lighthouse monkeyed with my post. #1 Migrations will not run on a fresh database should say: symlink /usr/local/ruby/bin -> /usr/local/ruby/1.9.1-p129/bin

ok. so maybe rails has done this before :) turns out that if you use rails -r /path/to/ruby it will reset all your shebangs. so don't need that. i have legacy code and don't run rails to create new projects at all so i missed that option. so that just leaves console using path/irb. i defer to the great oz that is rails core.

Any updates to this ticket?

Automatic cleanup of spam.

Any chance of getting this prioritized some day? JRuby itself starts up pretty fast, Rails less so...and with this double-booting it's almost unbearable.

Here's a gist showing the differing times from starting up IRB alone, IRB with RubyGems (with a tweak in my env to speed it up), IRB with RubyGems and boot.rb, and the Rails 3 console. Compared to IRB alone, Rails 3's console takes an order of magnitude longer to start up, and compared to IRB + boot.rb, it's almost 2x, as you'd expect from double-initializing.

https://gist.github.com/713286

Also, to make it sound less snarky...I'd happily work with someone to get an acceptable patch put together.

I haven't really begun digging around in Rails3 yet, but I'm pretty sure your benchmarks should be including config/application.rb not config/boot.rb. I think you'll get much more similar times then because boot.rb is only doing the Bundler setup now.

You'll get more similar times because... I think your change has been included in Rails3 as part of their general improvements. Looking in railties/lib/rails/commands/console.rb I see IRB.start now.