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

11 comments
Comment actions Permalink

What's the status of this? My experience is exactly as described here, but it's 8 years later... I'm on MacOS. 

1
Comment actions Permalink

 I also am still experiencing this - it takes way longer to run RSpec tests in Rubymine than in the terminal.

1
Comment actions Permalink

How do you run tests in RM (using rake or "all specs in directory")?

Regards, Oleg.

0
Comment actions Permalink

Hi Oleg,

I just hit the green button that looks like a play button (shortcut Shift + F10) to run the specific rspec file.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.
0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

:( 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.

0
Comment actions Permalink

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?

0
Comment actions Permalink

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.

0

Please sign in to leave a comment.