Posted on

Fixed: My i7 Intel Dell Laptop is Ridiculously Slow

Most of the Google results I found when digging around on this subject pointed to usual boring causes of slowness: too many programs being run on startup (which you can test with ms-config if you’re running Windows), anti-virus software, and other boring stuff of that sort. In my case, I had been running Ubuntu so most of those tips are moot. But to be thorough, I did remove practically any and every resident program that was running on what should have been a zippy Dell Latitude E6520 with a i7-2720QM (2.20GHz, 6M cache) processor.

And yet, running a utility that averaged about 5 seconds on my desktop consistently took 30 seconds on my laptop. Except for every once in awhile, when it would take 6 or 7 seconds.

Before splurging for a new laptop, I decided to take a peek through my BIOS settings and managed to stumble across the culprit: the Intel “Speed Step” feature. On my Dell, this was under the “Performance” settings. I guess that the idea of Speed Step is that the i7 powers itself down when it decides you’d like your system to perform like a 486. Whatever the logic is that determines when to power down was clearly NOT working as intended on my laptop. After disabling Speed Step, I have been running for the entire day at speeds very similar to my desktop.

Hopefully someone else thinks to Google for this problem and find themselves helped by a similar approach. FWIW I suppose that this might mean that the laptop uses more battery, but you can be an informed consumer about whether you want to run fast or power-efficiently.

Posted on

Fix: IRB pasting is super slow, typing in ruby debugger has lag

After numerous hours spent trying unsuccessfully to fix this problem by following the instructions outlined on a few StackOverflow posts, Jordan presented a recipe for fixing this problem (that actually fixed the problem) today.

The essence of the issue is that the readline package that gets installed with REE is by default some bastard version that lags, at least on our Ubuntu and Mint installations. Installing the rvm readline package did not fix it for either of us, nor did an assortment of experiments on compiling REE with different options. Here’s what did:

$> sudo apt-get remove libreadline6-dev
$> sudo apt-get install libreadline-gplv2-dev
$> rvm remove ree
$> rvm install ree

One problem you may encounter is that if you’re avoiding newer versions of Ubuntu until admit defeat about Unity, the “libreadline-gplv2-dev” package is by default only present in Oneiric and above. Here’s where I found the package versions that worked with Maverick: https://launchpad.net/~dns/+archive/test0/+sourcepub/2252776/+listing-archive-extra. After downloading the packages from this link, the install sequence became

$> sudo apt-get remove libreadline6-dev libreadline5
$> sudo dpkg -i libreadline5_5.2-9~maverick0_amd64.deb
$> sudo dpkg -i libreadline-gplv2-dev_5.2-9~maverick0_amd64.deb
$> rvm remove ree
$> rvm install ree
Posted on

Rails 3 Unit and Integration Tests Slow: So Fix It

Another topic for which there is no shortage of Google results, but none that have really helped us to figure out why it takes upwards of three minutes for our tests to start. Finally reached my breaking point today and decided to track down what was behind the painful slowness of our test invocation.

The answer, for us, was the time it takes to purge and re-load the database when tests were starting. To figure this out, I simply ran

rake test --trace

And observed as we sat for two minutes on the db:schema:load. Ouch.

The good news is that, since we don’t use fixtures (chill runs down spine at the thought), there is really no need for us to purge our test DB every time we want to invoke tests. So, I decided to hack together a patch to allow tests to begin without the usual purge/load dog and pony show that goes with starting tests. If that’s the sort of thing that you’d be into, here’s the code you need to make it happen (in Rails 3, not sure how this might vary for Rails 2):

Rake::TaskManager.class_eval do
  def remove_task(task_name)
    @tasks.delete(task_name.to_s)
  end
end

Rake.application.remove_task('db:test:load')

namespace :db do
  namespace :test do
    # Re-creating the DB every time we run tests sux...
    task :load do
    end
  end
end

Basically, the first bit is to undefined the existing “db:test:load” method, and the last part redefines db:test:load to do nothing. Add this as a mixin in your config/initializers directory and you should be golden.

If you do want to re-create your test database on occasion, you can still do that by running

  rake db:test:purge RAILS_ENV=test
  rake db:schema:load RAILS_ENV=test

Chances are that the RAILS_ENV isn’t even necessary there, but I don’t really feel like testing whether or not it deletes my main database atm.

Using this, our test start time dropped from about 3 minutes to 10 seconds. And that’s change that we can believe in.