Ship It! LIVEShip It! LIVE
home about services writing contact

We develop, test, and create fine software products, and design creative solutions to your problems.
The development of software is an intrinsically creative process. We are dedicated to improving our mastery of the art.
Links · RSS Feed
Popular Pages

More practical advice from the pragmatic crew. This is another excellent book from the guys at Pragmatic. In this book Jared and William cover pragmatic project management with down to earth advic...
-Jack D. Herrington
...It would be really nice if, as an industry, we could stop being such a bunch of screwed-up clowns and start living up to our potential. Ship It! is one of the things that could help, if only tho...
-Mike Gunderloy
Quoting Watts Humphrey, "Developers are caught in a victim's mentality." We never think it's our fault, it's always somebody else's.
-Jared Richardson

Using C in Rails (Jul 10)
I'm giving a talk at OSCON on extending your Rails application with C and I thought I'd blog on a few gotchas as I work on the demo application and publish my preliminary "benchmark". (Don't get upset... it's not really a benchmark.)

I'm going to use two technologies for my C integration. RubyInline is used for dropping C in line to your Ruby code, hence the clever name. It's really easy to use and has very good docs.

The other technology is the plain old Ruby C Extensions. This is also very easy to use.

RubyInline compiles the C code on your first pass and then reuses the compiled code. Putting that file in a controller that you reload with every client visit really messes it up. This reload is done in development mode, not production mode.

So you have two options, the first is to run your Rails app server in production mode. For Mongrel, try "mongrel_rails start -d -e production"

The other option is to put your Ruby class containing your C code in a location that isn't reloaded every time. I used the lib folder. On the other hand, this really slows down your Rails debugging. You have to restart your Rails app server between edits to the C code. It's almost like having to compile everything! ;) It'll drive you nuts.

Thanks to this Ruby mailing list thread for the answer to that problem.

Another issue to be aware of is that RubyInline seems to want your C code inside of double quotes. That's not a problem until you want to have a double quote in your C code. A printf perhaps? Just use the

%Q{ Put your string in here}
notation. That will quote anything within the brackets. Put all your C code within the brackets and you'll be fine.

Finally, when you do something like a factorial example, don't let the results get too big. Your C code will silently overflow and return a zero to you, making you think you've got a simple error in your C code. :) Just keep the results reasonable and you'll be fine. For the record, factorial of 500 isn't reasonable.

While RubyInline is easier to get started with, I think regular C extensions are easier to use. But something to remember... if you've been coding and developing with C extensions in a shell, you may have just been doing "make", and that works fine for that directory. But not for Rails. Don't forget that the rest of the system can't see your code until you do a "make install".

For my demo, I'm just using a boring, non-realistic factorial example. And I'm having to run it 50,000 times in a row to slow it down enough to have meaningful differences in the times. And that's on a laptop.

Raw ruby calculates factorial twelve 50,000 times in 0.53336 seconds, or just under 2 reqs/sec. That's within a Rails controller.

Using RubyInline, it takes 0.04724 seconds or 21 reqs/sec. Ten times faster.

C Extensions runs the same code in 0.02681 seconds or (37 reqs/sec). Almost twenty times faster.

I did notice that for larger factorial values, the time difference between RubyInline and C Extensions seemed to shrink significantly, so there must be some startup time involved... But the message is clear.

Write your application with all the speed of development that Rails can give you. Get it running, then bench it. If you need more speed than the runtime can provide, you can always drop back to doing the processor intensive work in C, giving you the best of both worlds.

Should you plan on using C in your next Rails application? No way. I'd bet that more than 99% of applications don't need that much performance. But if you do, it's nice to know it's available.

Category: Rails

New England Software Symposium (2008-09-12)
Back in Boston! I'll be speaking on Saturday and Sunday.
Pacific Northwest Software Symposium (2008-09-19)
Back on the west coast. I'll speak (and keynote) on Friday and Saturday in Redmond.
Agile Development Practices (2008-11-10)
Any conference in Orlando is good, but this one is great!
Agile One: Boston (2008-11-18)
The first Agile Experience was a huge success. Tell your manager about this one.


© 2007 Agile Artisans.