Rspec Rails high overhead


#1

Greetings,
I found out that running RSpec on Rails takes too much overhead. It
takes
more than 16s per run although the specs only take less than 6s, like
seen
below. That means almost 11s overhead.
I can’t find the bottleneck. I use latest rspec, and rails 2.2 on
Debian.

$ time rake spec

sys 0m2.266s

I know that Debian’s ruby is slow. So I tried using enterprise ruby. Not
much difference

$ time /opt/ruby-enterprise/bin/ruby /var/lib/gems/1.8/bin/rake spec

sys 0m1.735s

The overhead is also felt when using autospec. Even using sqlite’s
in-memory-db doesn’t change much.

Can anyone give me hint about what happens and what to do to overcome
it?

Thanks all.


#2

On Sat, Jan 3, 2009 at 6:58 PM, Reza Primardiansyah <
removed_email_address@domain.invalid> wrote:

I found out that running RSpec on Rails takes too much overhead. It takes
more than 16s per run although the specs only take less than 6s, like seen
below.

The killer is the time it takes to load environment.rb, which loads
Rails,
runs initializers, etc. The rake spec task also tears down and recreates
the
test database, but that’s not as significant.

The solution to the first situation is spec_server, which loads the
environment once, then stays in memory as a DRb process. By passing
–drb to
the spec command, RSpec will have that process run specs. The solution
to
the second situation is to not run rake spec, but instead use spec or
autospec.

All that said, I haven’t had as much joy from spec_server as I have in
the
past. Too often it seems to not load changed models. But this might be
related to a patch I had to apply to even get it to run. Things seemed
to
have changed with Rails 2.2.2 and/or RSpec 1.1.11.

///ark


#3

On Sun, Jan 4, 2009 at 3:58 AM, Reza Primardiansyah <
removed_email_address@domain.invalid> wrote:

much difference

real 0m12.033s
user 0m9.948s
sys 0m1.735s

The overhead is also felt when using autospec. Even using sqlite’s
in-memory-db doesn’t change much.

Can anyone give me hint about what happens and what to do to overcome it?

How long does ruby script/server take before the server is up?

Aslak


#4

On Sun, Jan 4, 2009 at 6:57 AM, Nick H. removed_email_address@domain.invalid
wrote:

Mark, would you mind explicitly telling us/me how you get the ``spec’’
command to run within DRb, please?

I use spec rather than script/spec to run specs. script/spec runs my
specs
twice. I also use rake spec:server:start rather than script/spec_server,
but
both commands do work for me.

The problem now is that if I change a model or lib file, it’s not
reloaded
by spec_server. I have to stop and restart spec_server for the change to
be
picked up. This means I can’t really use it. (To the powers that be, I
apologize for not filing a proper bug report.)

This is what happens I try [and fail] to do so:

http://gist.github.com/43070

That sequence “works for me,” I’m afraid.

///ark


#5

On Sun, Jan 4, 2009 at 2:52 PM, Mark W. removed_email_address@domain.invalid wrote:

On Sun, Jan 4, 2009 at 6:57 AM, Nick H. removed_email_address@domain.invalid wrote:

Mark, would you mind explicitly telling us/me how you get the ``spec’’
command to run within DRb, please?

I use spec rather than script/spec to run specs. script/spec runs my specs
twice.

That’s fixed, so I’m guessing you’ve got a mixture of old and new
generated files.

I also use rake spec:server:start rather than script/spec_server, but
both commands do work for me.

The problem now is that if I change a model or lib file, it’s not reloaded
by spec_server. I have to stop and restart spec_server for the change to be
picked up. This means I can’t really use it. (To the powers that be, I
apologize for not filing a proper bug report.)

Apology accepted as soon as you do :slight_smile:


#6

On 2009-01-03, at 23:17, Mark W. wrote:

///ark

Mark, would you mind explicitly telling us/me how you get the ``spec’’
command to run within DRb, please?

This is what happens I try [and fail] to do so:
http://gist.github.com/43070

Cheers,
Nick


#7

Aslak,
The best time I get is 6.3 seconds. I’m using “time script/server”
command
and hitting Ctrl-C immediately after I see “** Use CTRL-C to stop.”


#8

On Sun, Jan 4, 2009 at 1:03 PM, David C.
removed_email_address@domain.invalidwrote:

I use spec rather than script/spec to run specs. script/spec runs my
specs
twice.

That’s fixed, so I’m guessing you’ve got a mixture of old and new
generated files.

I did re-gen with .16, but still got that result.

The problem now is that if I change a model or lib file, it’s not reloaded

by spec_server. I have to stop and restart spec_server for the change to
be
picked up. This means I can’t really use it. (To the powers that be, I
apologize for not filing a proper bug report.)

Apology accepted as soon as you do :slight_smile:

The problem, of course, is the “proper” part. But I will try to get at
it -
I love spec_server!

///ark


#9

On Tue, Jan 6, 2009 at 4:29 AM, Reza Primardiansyah <
removed_email_address@domain.invalid> wrote:

Aslak,
The best time I get is 6.3 seconds. I’m using “time script/server” command
and hitting Ctrl-C immediately after I see “** Use CTRL-C to stop.”

Ok, so you have 5 seconds of additional overhead. I’m guessing that
RSpec
takes maybe 0.5-1 seconds of the remaining 6 seconds overhead, and that
plugins, gems and other code the rest. Maybe you’ll find out more with
http://ruby-prof.rubyforge.org/

Aslak


#10

On 6 Jan 2009, at 13:02, aslak hellesoy wrote:

RSpec takes maybe 0.5-1 seconds of the remaining 6 seconds overhead,
and that plugins, gems and other code the rest. Maybe you’ll find
out more with http://ruby-prof.rubyforge.org/

Aslak

Worth mentioning that I went down a huge rabbit hole with a similar
problem (slow load of rails environment) a few weeks ago, and it
turned out that all I needed was a reboot. (Mac OSX Leopard). Boy, did
I feel like a chump!

wrote:

sys 0m1.735s

rspec-users mailing list
rspec-users mailing list
removed_email_address@domain.invalid
http://rubyforge.org/mailman/listinfo/rspec-users

Matt W.
http://blog.mattwynne.net
http://www.songkick.com