How I Made My Ruby Project 10x Faster

http://www.adit.io/posts/2013-03-04-How-I-Made-My-Ruby-Project-10x-Faster.html

by jjhageman • 13 years ago

97 57 13 years ago

adit.io

scosman• 13 years ago

All of the performance improvements combined were about 0.00002s per call. They came at the cost of simplicity.

grandalf2• 13 years ago

Great point. Simplicity is one of the main reasons to use Ruby, not performance.

catnaroek10• 13 years ago

Ease of use. Which is not the same thing as simplicity.

vidarh6• 13 years ago

That may be so, but sometimes, once your design has settled, you'll have hotspots you want to speed up.

Of course I hope nobody starts jumping through all kinds of hoops before they know that it matters...

egonschiele3• 13 years ago

In most cases I agree with you. In this case though, the speed penalty could have been an argument not to use contracts.ruby...and I wanted to avoid that :)

catnaroek10• 13 years ago

Runtime tests always cause a performance penalty. (And they do not prevent you from writing buggy programs! They just make the runtime environment yell at you if a bug is found.)

If you want to guarantee that a property holds for all the elements of a set (every possible running instance of a program), forget about the elements and work with the set's definition (the program itself).

vidarh6• 13 years ago

A thought for you: Testing with respond_to etc. is great. But there's a special place in hell for you if you get people to start testing against specific classes.

It's almost always a horrible anti-pattern in Ruby to do "kind_of?" tests or similar, unless you depend on a huge portion of the interface of said class. But almost always code that does tests like that really only depends on a method or two, and doing class based tests makes the code vastly less reusable.

I don't want to dissuade you from this project. There are useful things you can do with contract specifications in Ruby that'd be interesting to explore. But I do hope to dissuade you from having all those class based tests in your tutorial for example...

vidarh6• 13 years ago

Arguably, a lot of them came through improvements that did nothing to harm simplicity.

Removing the unnecessary callback, for example.

And ".times" is certainly more idiomatic than ".zip" for his case. It's a toss up between .each_with_index and .times, but really both will be readable enough. And from experience, you'll find Ruby devs that are unfamiliar with "zip", but not with "each_with_index" or "times".

"alias_method" is also far more idiomatic than grabbing a reference to the method - I don't think I've ever actually seem method() used in production code (not that I've explicitly looked)

cortesoft2• 13 years ago

This was my thought as well. This is one of the main fallacies of code optimization; unless these functions are called a LOT, you very well might be optimizing something that is not your bottleneck. You can see the author is missing this point because he talks about going from "20 seconds to 1.5 seconds." He is using those numbers as if they are real use case times, when in fact they are generated from an arbitrary amount of calls to a function.

So many times I will see people make code optimizations of this type to shave fractions of a millisecond from a function call at the cost of complexity, memory usage, etc. Meanwhile, most of the time their program is actually waiting on IO or something of the like.

Blind optimization is counter productive.

egonschiele3• 13 years ago

Why do you think this is blind optimization? When do you think an optimization like this would be appropriate? Can you give an example of a performance optimization you have made recently?

nonchalance• 13 years ago

You don't know what project he was using that gem for. It's very well possible that he did some tests and found that this contracts library was the bottleneck. If that were the case, then the approach makes sense.

Although, given the nature of the library, I highly doubt that was the bottleneck

orclev2• 13 years ago

Is it wrong that I was secretly hoping the answer was "I rewrote it in something that isn't ruby"?

rubiquity• 13 years ago

Wrong? Sometimes. Trendy? All of the time.

joemaller1• 13 years ago

At this point on HN, I was expecting a page that just said "I rewrote it in Go"

unknownian• 13 years ago

Or Erlang/Elixir.

plg• 13 years ago

"how I made my toyota tercel 5x faster... (I sold it and bought a porsche)"

rubyissofun• 13 years ago

Ruby is awesome, so yes that would be wrong. But is it wrong that I was secretly hoping the answer was to abandon the project?

Contracts are not needed and it obfuscates the error raising. Just use plain Ruby if you need to raise an exception. I'm will seriously quit using Ruby if someone makes me use contracts.

But it looks like a fun project to write. Nothing wrong with that.

cmccabe• 13 years ago

Yeah, it sounds like he should just use a statically typed language. (yes, I am aware that types != contracts, but they're similar enough that my statement still stands)

nfm• 13 years ago

Does anyone know what's going on behind the scenes with `alias_method`? I'm curious to know how it's implemented such that it was actually faster!

jfarmer• 13 years ago

alias_method is faster than what he did before because he's replicating a bunch of internal logic at run-time, e.g., binding "self" to the correct thing. Somewhere deep in the bowels of the Ruby interpreter it's going to be doing the same thing, except it has the opportunity to create the binding statically at define-time. Likewise, he's calling a method on a Method object to invoke the original method vs. invoking the original method directly.

This might speed things up a little more, too:

  alias_method :"original_#{name}", name
  class_eval %{
    def #{name}(*args)
      self.original_#{name}(*args)
    end
  }

"send" is going to be using extra machinery in the same way, although I think "send" also circumvents certain protections like public/private, so I'm not 100% sure where in the Ruby method invocation process it fits in. "send" might be closer to the metal, but a pre-defined method name would have the opportunity to cache certain things in the invocation process.

blakeshall• 13 years ago

I really enjoy write-ups like these. Anyone have a resource that is primarily blog posts/articles like this?

karlmageddon• 13 years ago

The rest of his block is pretty great -- http://www.adit.io/index.html

Some of them have pretty cool original illustrations, too!

Pxtl• 13 years ago

tl;dr: bolting on a dynamic-typed imitation of static-typing is slow.

Locke16893• 13 years ago

Contracts are not types and do not really behave like types in many ways.

vidarh6• 13 years ago

They behave enough like types that the library in question is pretty much as far from idiomatic Ruby you get if you use it like in his examples and tutorial.

Constraining inputs to a specific class, for example is a huge, giant no-no. If you're going to make Ruby statically typed, then you're better off picking a language that's easier to make fast.

This is a pet peeve of mine as I've more than once had to work around arbitrary, stupid checks against specific classes in cases where meeting the "actual" contract of the method called would be down to implementing a simple method or two.

The tutorial hints at some possibly Ruby-ish possibilities, like contracts based on whether an object responds to a method, but all the focus seems to be on class comparisons.

I do like the idea of specifying contracts, fwiw, as long as they're focused on behaviour and not on matching specific classes.

I don't, however like the idea of specifying them in the class files. Specifying them in separate files, that could be loaded when wanted, and that could also be used by a testing app to do some degree of automated testing of limits etc., or by other apps to do limited static analysis would be interesting.

catnaroek10• 13 years ago

And their core, types and contracts are the same thing: logical propositions asserting properties of a program that have to be enforced somehow. The difference is the method of enforcement: types are enforced via static analysis and contracts are enforced via runtime checks.

Oh, and if what you meant was "types cannot check pre/postconditions", then you should have a look at dependently typed languages. Some dependently typed systems can express any proposition expressive in first-order predicate logic. (The downside is that satisfying the type checker becomes bloody hard.)

vidarh6• 13 years ago

I'd go for:

Avoid creating objects that aren't needed, and avoid method calls.

For the most part that's what his changes boils down to. In other words: Reduce complexity. It's very easy to cause Ruby code to blow up performance wise because you don't realize how many extra objects you create (arrays and hashes + lots of chaining or functional inspired method that returns copies instead of mutates == boom) or how many extra method calls you trigger behind the scenes.

aaronblohowiak• 13 years ago

More generally, avoid duplicating effort: memoize as much as possible, including branching over invariants.

Demiurge• 13 years ago

Did you rewrite it in Go? I guess I should read the article.

OK, now that I've read it, profiling ftw :-)

mosselman• 13 years ago

Would have been more useful if there were more before-after examples.

aneth42• 13 years ago

Sort of takes away from the "power" and "beauty" of the language when you need to dissect your code and understand the runtime to get reasonable performance.

rubydoobydoo2• 13 years ago

I can't believe this is the top comment at the moment.

First, let's get something straight. This project wasn't necessary, because you shouldn't be type checking in Ruby if it is written correctly. That's basically what contracts are, at least in this case.

To address your concern, Ruby's performance is plenty fast- like Java entering the early 2000's fast. (You probably don't get my reference, but in the mid-1990's, people complained Java was slow.) No one at work has complained about the performance of our Rails app running on Unicorn, and we've not had to do one performance tweaking iteration ever.

annnnd• 13 years ago

I can't believe this is not a top comment anymore.

I don't have enough experience with Ruby to comment about it, but as far as Java is concerned, people (myself included) are still complaining it is slooooooooo... <let me pause a bit to collect garbage>... ooow. Don't get me wrong, Java is an excellent language which has plenty of other benefits (as I guess Ruby does too), but raw performance is not one of them.

aneth42• 13 years ago

I do get your reference. I was a java developer since 1996. 2000 was 13 years ago and ruby is far older than Java was then, so hardly a valid comparison.

I am a ruby developer and ruby is dog slow.

How I Made My Ruby Project 10x Faster

Related Stories