…
Colin, do you have a sample application? Next, it really depends
on your overall system and Rails app configuration. For example,
if you don’t have enough RAM, your system move data from memory
to the disk and vice-versa. This is a huge performance hit. Can you
provide more information?
I have 1GByte RAM and while running the test it shows less than half
used and the disk is not rattling. The processor shows 100%
utilisation whilst the test is running, with rake being the process
using most of it.
I have tried making a new rails 3.0.3 app
rails new testruby
then using rvm to switch between 1.8.7 p302 and 1.9.2 p136
On each ruby I ran
time rake db:migrate
a couple of times to let the disk cache settle out then for 1.8.7 I got
real 0m2.111s
user 0m1.804s
sys 0m0.220s
and on 1.9.2
real 0m4.098s
user 0m3.512s
sys 0m0.424s
I also tried rake test and got, on 1.8.7
real 0m3.615s
user 0m3.104s
sys 0m0.316s
and on 1.9.2
real 0m6.487s
user 0m5.320s
sys 0m0.684s
It seems as if 1.9.2 takes about twice as long for some reason.
Colin
Colin, do you have a test case that I can run locally? Or can you
tell me the specifics? Next, I’m not sure that 1 GB RAM is sufficient
because other resources outside the actual application uses the RAM.
For example, on my slower machine, iMac, with 4 GB Ram, the RAM
utilization for some common applications are as follows:
Safari 5 ~554.0 MB
Textmate ~96.1 MB
Terminal ~14.0 MB
Chrome ~199.6 MB
Firefox ~128.2 MB
and so on
Note: The above doesn’t include any of the OS specific processes but
you can see that this adds up. Also, most modern OS will reserve RAM
for its use that cannot be used by the end user. Just something to keep
in mind.
Lastly, in regards to running spec, I tend to use Ruby Spork gem because
anytime you do ‘rake spec’, the Rails framework needs to be loaded before
the application specific code can be executed. This is also true when running
‘rake db:migrate’
Good luck,
-Conrad