

ARel 2.0: Active Record Performance in Rails 3.0.2 - mudgemeister
http://engineering.attinteractive.com/2010/10/arel-two-point-ohhhhh-yaaaaaa/

======
gleb
This is awesome work. I've been following these commits on GitHub and it's
great to see AR being optimized.

Unfortunately there is not enough info in these benchmarks to tell whether for
a large production app 3.0 might be 10 times slower than 2.3 for that
particular find you are benchmarking. Or 10 times faster. Or the same.

Here's why -- for MRI the time spent on each GC run is a function of total
process size/# loaded objects, which is mainly a function of your code size.
In a trivial test case you can run GC in a few milliseconds. In a production
app it's 100ms+. Simply by loading more code into the benchmark it's possible
that we can change results completely.

When benchmarking ruby code it's better to keep runtime, # of memory
allocations and size of memory allocation separate and report all 3. Meaning
you run the test with GC off and patch the interpreter to get the memory
allocation info.

Different users will have different tradeoffs between runtime costs vs GC
costs depending on the app size, ruby interpreter used, GC tuning parameters,
available RAM, etc. It's certainly valuable to also come up with general "5x"
number, but that should assume and state some reasonable values for the above.

------
texel
Admit it: you just wanted to use an AST so that you could easily convert SQL
to and from XML for an upcoming talk.

~~~
tenderlove
How did you know? ;-)

~~~
tvongaza
And we thought SQL was enterprise ready already!

------
joevandyk
Are there tests in the ActiveRecord code base to prevent performance
regressions?

------
mattknox
technical erratum: if each node in the list adds all the previous nodes as new
objects, then with 4 nodes, the total number of objects is 10, not 24, and the
overall order of the operation is O(n^2). It's still cool that he is faster,
and cooler that it is using an AST, which seems to me like the right solution.

~~~
tenderlove
Oops! You're right. Should be O(n^2). I'll update. :-)

------
tonycoco
Great work. This is why the Rails community is so damn solid.

------
stephencelis
I think 3.0.2 is a typo, as 3.0.1 is referenced later in the article, and was
just tagged here:

<http://github.com/rails/rails/tree/v3.0.1>

(And released! It's available via `gem update'.)

~~~
tenderlove
No, it's really 3.0.2. 3.0.1 is a security release only. I've updated the
article to remove mentions of 3.0.1. Thanks for catching that!

~~~
tptacek
The 3.0.1 nested assign bug is pretty terrible; wouldn't be the worst thing in
the world to remind your readers to update to it ASAP.

------
rnicholson
Why is

attr_reader :foo

faster than

def foo;@foo;end

Is this in 1.9.x? or 1.8.x? or both?

~~~
texel
Courtesy of Evan Phoenix... apparently in MRI, attr_reader doesn't create a
method, instead creating a NODE_IVAR in the method table of the class. This
circumvents method creation/invocation overhead and is therefore faster.

------
ambertch
haha! I didn't know this guy had a blog. I've heard Aaron Patterson speak, he
is crazy and awesome at the same time, IE crawesome. Or, awezy (aussie?)

~~~
jbarnette
Aaron's real blog: <http://tenderlovemaking.com>

------
heresy
Good article, though there's a hint of "I just had my coffee" in it.

Do programmers dream of O(n!) sheep?

------
cannikin
Release date?

