Speedup Ruby 1.9.3 On Windows

Ruby is a great programming language, but unfortunately it does have some problems when using on Windows. One of it’s biggest drawbacks is it’s slowness when loading files. This is also slower than it ought to be on Unix platforms, but not as slow as on Windows. Thankfully there is some work going on to make it faster in future versions. It’s already possible to make it faster yourself!

Benchmarks

I will conduct two types of benchmarks. Firstly i’m gonna create an empty Rails 3 project and see how much time would it boot up. Secondly there is a project called measurements which allows to perform some operations on your Ruby and one of these are benchmarks for loading files. Let’s see how it goes for Ruby 1.9.2, 1.9.3 from RubyInstaller and patched 1.9.3.

These benchmarks show that Ruby 1.9.2 is really slow and patched 1.9.3 got about 50% performance boost compared to regular 1.9.3. That’s something to be happy about! I’m using average laptop PC which means that if you have a more decent hardware then the results might be very different from me.

Prerequisites

The following components are needed to speedup your Ruby:

If you’d like to skip all that hassle of building all the things yourself then you can download already prebuilt patched Ruby versions too! Read the “Faster Way” part about that below.

Get Fenix

Fenix is a Ruby extension written by Luis Lavena. Luis is a really helpful and great guy, at least when it comes to Ruby on Windows. He is part of the Ruby core team, is the main man behind RubyInstaller and has created many nice libraries like sqlite3-ruby, rake-compiler and many others.

Back to Fenix. It changes File.expand_path method to be faster. All the 50% speedup seen from the benchmarks were coming from this change since this method is called more than once when loading files. Pretty impressive or rather sad bottleneck in Ruby. Get the Fenix extension, compile and benchmark it:

Not bad benchmark results.

Patching & Compiling Ruby

Unfortunately only File.expand_path method is faster when using this extension, but there’s Ruby’s require and load methods, which also execute expand_path, but they will do so by using internal C expand_path function instead. Solution for that problem is to patch Ruby code to use Fenix.expand_path internally also! First step would be to clone Ruby itself (make sure that line endings are not converted by Git):

Apply the patch created by Luis:

`git status` shows us that file.c and load.c files are modified. It’s time to start compiling Ruby itself. Best way to do that would be to use RubyInstaller itself (how ironic, we’re using Ruby to build Ruby). Make sure to disable ANSICON too since it is known to cause problems during the compilation process:

This takes some time and if the process raises any errors, just try again. If there’s still errors don’t hesitate to write to RubyInstaller mailing list or contact Luis directly. He’s very helpful, as i already stated above.

After the process is done “install” new Ruby with Fenix and make sure that it’s used by setting environment variables too:

Make sure that the PATH and RUBYOPT environment variables are set permanently. And try it out if it’s faster for you too!

Faster Way

In case you don’t want to spend your time cloning, compiling and testing then there is a faster way to boost your Ruby. There exists a project called The Code Shop, which tries to solve the Ruby performance problem on Windows. It makes different builds available to download, each experimenting with different set of patches. I can recommend tcs-ruby193_require_winio_fenix-20111113 because it seems to be the fastest. Here are some benchmark results:

Fenix is already precompiled into these builds. You still need to compile and install Fenix and set PATH and RUBYOPT environments as described above.

In Conclusion

The main point of this post is that things aren’t always as rosy as they could be, but it’s possible to make them better. It is really valuable that you give feedback to projects like The Code Shop (e.g. what are your benchmark results) so the final result could get better in the future without any additional hassle for everyone. I hope that you can now start your engines much faster!