rspec runner extremely slow
I have a simple non-rails project that consists of one simple class and one simple rspec file.
When I run "rspec spec -p" from the command line it executes and returns in about half a second.
When I run the same spec from within RubyMind it takes 2.5 seconds. Nearly all that time is spent in the "Initializing Tests" phase, as the actual test execution time is listed as .01 seconds.
Why is there such a huge discrepancy between the command line rspec and RubyMine's rspec, and how can I speed RubyMine up?
Thanks,
Jonah
请先登录再写评论。
What's the status of this? My experience is exactly as described here, but it's 8 years later... I'm on MacOS.
I also am still experiencing this - it takes way longer to run RSpec tests in Rubymine than in the terminal.
How do you run tests in RM (using rake or "all specs in directory")?
Regards, Oleg.
Hi Oleg,
I just hit the green button that looks like a play button (shortcut Shift + F10) to run the specific rspec file.
Hi Jonah,
sorry for delay (it is too easy to postopne an investigation when you have bugs to fix :()
I've tried both rspec from command line and fomr RM (4.5.4) and I see not noticable difference.
Though I'm on Windows and everything is not so fast here ;)
To run RSpec tests RM does call rspec, so we could two possible areas which affect tests' performance:
creating child process (which should not be a great deal everywhere except Windows) or our formatter.
Could you please try to run the same command as RM in command line and see if the formatter is the cause of the problem.
Regards, Oleg.
Hi Oleg,
When I paste in the command directly to the command line it doesn't work. I have tried both:
C:\RailsInstaller\Ruby1.9.2\bin\ruby.exe -e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) C:/RailsInstaller/Ruby1.9.2/lib/ruby/gems/1.9.1/bin/rspec C:/Users/JG/Dropbox/sinatra/1card/spec/player2_spec.rb --require teamcity/spec/runner/formatter/teamcity/formatter --format Spec::Runner::Formatter::TeamcityFormatter
and got this error:
C:/RailsInstaller/Ruby1.9.2/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:
36:in `require': no such file to load -- teamcity/spec/runner/formatter/teamcity
/formatter (LoadError)
So I tried adding the full path to the formatter
C:\RailsInstaller\Ruby1.9.2\bin\ruby.exe -e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) C:/RailsInstaller/Ruby1.9.2/lib/ruby/gems/1.9.1/bin/rspec C:/Users/JG/Dropbox/sinatra/1card/spec/player2_spec.rb --require "C:\Program Files (x86)\JetBrains\RubyMine 4.5.4\rb\testing\patch\bdd\teamcity\spec\runner\formatter\teamcity\formatter" --format Spec::Runner::Formatter::TeamcityFormatter
In the first case I get this error:
C:/RailsInstaller/Ruby1.9.2/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:
36:in `require': no such file to load -- teamcity/utils/logger_util (LoadError)
from C:/RailsInstaller/Ruby1.9.2/lib/ruby/site_ruby/1.9.1/rubygems/custo
m_require.rb:36:in `require'
Let me know the exact test you'd like me to perform.
Thanks.
Hi Jonah,
you need to add C:\Program Files (x86)\JetBrains\RubyMine 4.5.4\rb\testing\patch\bdd, C:\Program Files (x86)\JetBrains\RubyMine 4.5.4\rb\testing\patch\common,
and C:\Program Files (x86)\JetBrains\RubyMine 4.5.4\rb\testing\ to load path (-I ruby option)
Regards, Oleg.
Okay thanks Oleg.
So I got it run in command line now, and the results are:
Command line version is equally slow as RM version of the tests. Both are around 3 seconds.
To compare, the cmd line "rspec spec" runs in under .5 seconds.
:( it looks like our formatter's code is not very optimal. Could you please file a performance problem about this in our tracker (http://youtrack.jetbrains.net/dashboard/RUBY)
Thanks in advance, Oleg.
Hi Oleg,
Just to clarify your theory here: The formatter is essentially just doing string parsing, right? So we think that a string parsing job on a small data set is taking 2.5 seconds? That seems hard to believe, even for unoptimal code. How could it be?
Hi Jonah,
first of all it could be just slow inicialization (we loads formatter.rb at startup),
but it also could be slow formatter's code which is rather common and thus can be sub-optimal.
Of course this is just a guess from the information we have now if you have another theory feel free to share
it.
Oleg.