Carl Lerche talks about how to write fast ruby code. Yes, ruby is scalable. Scaling != speed. Focus of this talk is on speed. Ruby is fast enough for the vast majority of use cases.

“Slow code is your fault.”

How can I write fast code?
1. Write slow code: well-structured code that is easy to read. Don’t worry about performance the first time around. You can’t tell from the beginning what matters.
2. Use the scientific method.

  1. Define the question
  2. Gather information: where is time/memory being spent?
  3. Form Hypothesis: why is this chunk of code slow/memory hog
  4. Perform an experiment and collect data
  5. Publish results (restart if needed)

Need questions like: “why is action X taking 600ms? ” why is 60% of a Merb dispatch cycle in content negotiation?”  Why are my mongrel instances growing to 300MB of memory”

Some useful tools:

  • RBench
  • ruby-prof to generate profile data / kcachegrind:  for reading profile data
  • explain analyze log files
  • New Relix / five runs
  • memory_usage_logger
  • Bleak_house (memory leaks)

Garbage collector is a conservative mark and sweep garbage collector.  When it runs all your code stops. Each run can take 50-150ms.  Triggers befre grabbing more system memory (every 8MB).

Avoid creating unecessary objects.  Understand the difference between Ruby methods (e.g. the difference between reverse! and reverse).

DataMapper’s identity map is pretty awesome.

Beware of modifying large strings.

Don’t concat strings just to pretty print them across lines.  Do this instead:

     s = "Here is my long string" 
           " that continues"

Beware of closures.

No code is the fastest code.  Be lazy.  Don’t run code till you have to.

“Compiling your code.” Iterating is slow.  Ruby’s AST is fast. (This is a little crazy, but sometimes you need it.)

Make sure you have great tests, then when you optimize you can make sure you didn’t break anything.

Panel discussion at Golden Gate Ruby Conference

Shoes, Tim Elliott, framework for creating GUI apps. It is an application that embeds Ruby. It is written in C. It is designed to lower to bar for programming and make it fun. Not an MVC framework. Writing an app is more like writing a script. Written to be compiled an shared with your friends.

RAD, Greg Borenstein, open source hardware platform for doing hardware hacking. RAD is a framework for programming the Arduino physcial computing platform using Ruby. The Ruby code is coonverted into C code which is then compiled and run on the Arduino microcontroller. Working on a test suite that comes with a shoebox full of hardware, so you can check if things blink or bleep in the right order to see if your tests pass.

Adhearsion, Jay Phillips, a way of building telephony applications. You call into a phone number, then the Ruby call services the phone call. First app he wrote was using RAD to make it so he could make a phone call to unlock his door — he says everyone should go out and buy an Aduino controller and a bunch of LEDs and build something fun tonight.  Interesting thing about Ruby is that it allows you to “play with other people’s code.” He described a plugin system that was actually adopted from RAD.

Sinatra, Blake Mizerany, creator of Sinatra.  Sometimes MVC is too much.  Ruby is great for this.  Closures are awesome.  As Rack grows, Sinatra has been getting smaller.  Sinatra is a really strong Rack citizen.

Merb, Yehuda Katz lead maintainer.  (not talking about Merb) Hard thing about maintaining a framework is that they start with a clear mission, but as people build apps with the framework, there are requests where its hard to tell if this request is pushing application code into the framework  The best thing about Ruby is that all code is executed code.  You can define methods anywhere.  What is hard about Ruby.  It isn’t a slow language, but nothing is free.   The challenge is how to right lightweight code, yet is robust.

Rails, Josh Peek from the Rails and Rack core teams.  … interested in seeing how code can be shared between frameworks to strengthen the  ecosystem.

What features of the Ruby language make it effective for frameworks? meta-classes and closures (e.g. ActiveRecord),  “i don’t consider languages without closures to be powerful languages” (yehuda katz), defining methods on the fly, open classes, community (grass roots, people agree that they want to share code, this is unusual, agility in the community: moving to git and github, Rack, Ruby gems, RSpec, test-driven development as part of the project),  the agility of the community attributed to the agility of the language.

Is there anything about Ruby that encourages open source? the fact that it is a scripting language.  It is hard to hide your code.  The fact that Rails and Ruby are MIT Licensed, so corporations aren’t afraid to use it.  Even if 90% don’t give back, it increases the number of people who do.  Makes it so people feel free to try stuff out and modify it (and the fact that there are tests!)  There is high level of inter-operability with the “host language” for different Ruby implementations.

“If you are writing a framework, you should be writing it in the same way that you recommend people write plugins.  It’s really hard, but you have to do this.” — Yehuda Katz

“Allowing people to write test for their plugins is essential.” — Jay Phillips

What about the proliferation of Ruby implementations in different languages? kick-ass, as long as we keep holding the implementations to a high standard of compatibility.

Why was github so successful?  Why did so many projects move to git and to github so quickly? main benefit of github is the social network aspect.  When you put your code up on github, you aren’t creating an open source project, you are just sharing your code.  This decreases the overhead.  It increases people contributions.  “I think it has totally revolutionized the way people create open source software” (Jay Phillips)  Moving to git let’s you make really large changes and merge them back.  Things that are possible in git, would have been impossible in svn — you would fork forever instead of merging back in. (Yehuda Katz)

How to get the community to move to Ruby 1.9? get Rails to be on 1.9.  Why do you want the community on 1.9? speed improvements.  Yehuda Katz:  If you are doing something computationally expensive you might want to be on 1.9.  I benchmark everything.  Usually 1.9 is 2x and JRuby is 2.5x, but 1.9 has outliers of slowness.  I don’t think there is huge benefit to the community in moving to 1.9 (but I do think it is important that we all do move forward)  Jay Phillips: when JRuby and all the gems move to 1.9, the community will.  If I switch to 1.9 syntax, I will break JRuby, and I can’t do that.

Ilya Grigorik, gave a very informative talk “Ruby Proxies for Scale, Performance, and Monitoring”

Ilya describes a proxy server as his new favorite hammer. I can think of lots of cases where having an easy way to write a proxy server would come in handy. Mostly what we think of when we think of proxy servers is a “transparent, cut-through proxy,” but proxies can be useful for other purposes.

The problem that led Ilya to write a proxy server was benchmarking and performance testing. He started with HTTPPerf is good tool for simulating load, but it is only good for a single run. autoperf will make multiple runs and simulate more users.

em-proxy Very simple syntax to send traffic to both the production server and benchmark server (and only the response is returned from production). Real-time benchmarking against production traffic and user sees no performance hit. Only about 300 lines of code, shows the pattern for how to build a proxy server.

Ilya walked us through using EventMachine which has very concise, easy-to-read syntax for implementing proxy servers. This does not need to be restricted to http, but can work with any protocol.

Ilya described an interesting use case in detail. They created a proxy server which works with Beanstalkd, a distributed in-member work queue, where jobs are stored in MySql when they don’t need to be in memory.

Slides from the talk: