I hacked around to see if I could reduce the startup time. The idea is that most people will already have rails running in development mode locally, so one could offer using that for serving the assets to phantomjs, via a CLI flag.
First I switched off the spawning of the server, which gave me about half a second. The I realized the rails environment was still being loaded... teaspoon seems to couple to it in a few places, and maybe that can be avoided. So I disabled a few things more and required 'rails' and 'teaspoon' upfront in spec/teaspoon_env.rb, so
unless defined?(Rails)
ENV["RAILS_ROOT"] = File.expand_path("../../", __FILE__)
require File.expand_path("../../config/environment", __FILE__)
end
was effectively dead code.
With these modifications in place, teaspoon is still excercising my tests from the CLI. I probably broke a few things ;) Here are the numbers:
real 0m5.238s
user 0m4.033s
sys 0m0.825s
vs.
real 0m2.083s
user 0m1.435s
sys 0m0.164s
(I tried to do the comparison as fairly as possible, both times no bundle exec overhead, IO caches warm...)
Hi,
I hacked around to see if I could reduce the startup time. The idea is that most people will already have rails running in development mode locally, so one could offer using that for serving the assets to phantomjs, via a CLI flag.
See https://github.com/schnittchen/teaspoon/commit/632e70b401f02f15a6ea309bd98e01e58373e958 for what I did to teaspoon itself.
First I switched off the spawning of the server, which gave me about half a second. The I realized the rails environment was still being loaded... teaspoon seems to couple to it in a few places, and maybe that can be avoided. So I disabled a few things more and required 'rails' and 'teaspoon' upfront in spec/teaspoon_env.rb, so
was effectively dead code.
With these modifications in place, teaspoon is still excercising my tests from the CLI. I probably broke a few things ;) Here are the numbers:
real 0m5.238s user 0m4.033s sys 0m0.825s
vs.
real 0m2.083s user 0m1.435s sys 0m0.164s
(I tried to do the comparison as fairly as possible, both times no bundle exec overhead, IO caches warm...)