4 ms·
Wow! This is the first I've heard that RoR's ORM is slow. That's it's slow because Ruby is slow, is even more of a shocker. I'd love to hear some practical lim
by euroclydon 15y ago
Wow! This is the first I've heard that RoR's ORM is slow. That's it's slow because Ruby is slow, is even more of a shocker.
I'd love to hear some practical limitations that applications using Ruby and NHibernate face when querying data.
Is this slowness a reason that so many no-sql engines seemed to have sprung at the same time as RoR?
- psadauskas 15y agoIt is embarrassingly slow. I did some tests a couple years ago, on ActiveRecord 3.0.pre, and its 20x slower to initialize empty objects (no database access) than DataMapper, or just making empty Ruby objects & hashes. https://gist.github.com/260280 https://gist.github.com/260280 Edit: Ran it with AR 3.0.7 and 3.1.0.rc4. Granted, this is with a 2-years newer CPU, but 3.0.7 is a huge step up. 3.1 seems to have regressed again, I'll ping tenderlove about it when I see him. https://gist.github.com/fabfaf1bd8503fbf6d32 https://gist.github.com/fabfaf1bd8503fbf6d32
- wycats 15y agoBenchmarks on ActiveRecord before the work Aaron did on Arel (which was dropped in in 3.0.x due to the magnitude of the perfect issue/improvement) are not totally relevant today. There are still some issues, but there is still low-hanging-fruit as well, such as Aaron's work to add prepare statement caching to Rails 3.1
- ssmoot 15y agoYou'd reasonably expect to give up partial updates for prepared statements, and IIRC their performance benefit was fairly marginal anyways.
- tenderlove 15y agoYa, that is not acceptable. File a ticket for me (if you haven't already), and I'll fix this. As a side note, we need to start keeping benchmarks like this and graph over time. We (rails core) should know about regressions like this before the general public.