4 ms·
ARel 2.0: Active Record Performance in Rails 3.0.2
- texel 16y agoAdmit it: you just wanted to use an AST so that you could easily convert SQL to and from XML for an upcoming talk.
- tenderlove 16y agoHow did you know? ;-)
- tvongaza 16y agoAnd we thought SQL was enterprise ready already!
- stephencelis 16y agoI 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 http://github.com/rails/rails/tree/v3.0.1 (And released! It's available via `gem update'.)
- bphogan 16y ago3.0.1 is a security vuln fix. I don't think it contains this ARel stuff.
- stephencelis 16y agoAh, never mind. The mention of 3.0.1 later down in the article was corrected, or I misread.
- tenderlove 16y agoNo, 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 16y agoThe 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.
- tonycoco 16y agoGreat work. This is why the Rails community is so damn solid.
- joevandyk 16y agoAre there tests in the ActiveRecord code base to prevent performance regressions?
- heresy 16y agoGood article, though there's a hint of "I just had my coffee" in it. Do programmers dream of O(n!) sheep?
- mattknox 16y agotechnical 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 16y agoOops! You're right. Should be O(n^2). I'll update. :-)
- ambertch 16y agohaha! 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 16y agoAaron's real blog: http://tenderlovemaking.com http://tenderlovemaking.com
- rnicholson 16y agoWhy is attr_reader :foo faster than def foo;@foo;end Is this in 1.9.x? or 1.8.x? or both?
- texel 16y agoCourtesy 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.
- gleb 16y agoThis 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.
- cannikin 16y agoRelease date?