Waiting 8-10 seconds after spec_helper has finished about spork

[timcharper]

Have you tried using ruby-prof ? You can tell it to profile a specified block, then write the results for that block to a file.

[grosser]

The problem was that views loading + application loading just took longer in rails 2.3 (view loading because of the eager loading)
My current solution is to disable views reloading, but keep the application loading(since spork does not make much sense without...) -> see hacks below

the only real solution to this "your app is just too large"-problem cold be partially reloading e.g. reloading a file when it changes, but for this to work the e.g. odel must be unloaded, which i dont know how to do.....but maybe you got any further idea ;)

cheers mg

#insert before Spork.prefork
begin
  require 'spork/app_framework/rails'
  module Spork::AppFramework::Rails::NinjaPatcher
    #views are preloaded <-> spork must be restarted for view changes
    def delay_eager_view_loading
      puts "removed because i am too slow..."
    end
    # no application files reload <-> ultra-fast + any app/xxx change needs spork restart
    def delay_app_preload
      puts "removed because i am too slow..."
    end
    def delay_application_controller_loading
      puts "removed because i am too slow..."
    end
  end
rescue
end

[grosser]

Yeah i found a solution: disable Rails app/ eager-loading, now im back to 1 second startup :D

begin
  require 'spork/app_framework/rails'
  module Spork::AppFramework::Rails::NinjaPatcher
    # views are preloaded <-> spork must be restarted for view changes
    def delay_eager_view_loading
      puts "removed because i am too slow..."
    end

    # do not preload application files <-> fast test start
    def delay_app_preload
      ::Rails::Initializer.send(:define_method, :load_application_classes) do
      end
    end
  end
rescue
end

[grosser]

could you add something like Sporl.rails.eager_load_classes = false and Spork.rails.preload_views=false ?

[timcharper]

I think that should be the default. Though I'm wondering, have you tried just turning off cache_classes? What would be the consequence of that?

[grosser]

Yep, this would work too. cache_classes is the default for test environment, dunno why...

[timcharper]

ok, so I am thinking of having spork display a warning if cache_classes is true. Do you guys think that will be an appropriate solution?

[mcmire]

Setting cache_classes to false is a neat trick, actually. Just running a single, simple spec (with time rake spec SPEC=(the spec file)) I've reduced the time from 10.1s to 4.5s (my app is bloated so I think that's probably why it's not like 1.0s). I think displaying a message of some kind would be good.

[BryanDonovan]

Wanted to let you know that I've tried the various options listed in this thread, and found the following:

• The two NinjaPatcher blocks speed up test runs substantially, even with cache_classes set to false.
• The first NinjaPatch decreases load time more than the second one does.

This is on Rails 2.3.5, spork 0.8.1, rspec 1.3.0, rspec-rails 1.3.2, ruby 1.8.7-p174 on Mac OS 10.6.3

[mcmire]

(I had something here but it was wrong so let's try again)

I'd like to add: setting cache_classes to false and overriding delay_eager_view_loading to do nothing is a big help, but I also noticed that it took about a second for Spork to reload routes, so I decided to override delay_route_loading as well. Since I don't edit routes.rb that much, I figured it was a good tradeoff if I have to restart Spork when I do that. So here's what we're including in our spec_helper: http://gist.github.com/530601. After all three changes, running a single spec in our app went down from 7.4s to 2.8s.