There is still lots of optimizations to make. On the JIT side, there is still no inlining, which opens the door to much more aggressive optimizations. But also on memory as well. There was a lot of improvements done on the Ruby garbage collector for 3.3, but there's still a lot of room for improvement, and a few fine folks at Shopify are looking into making the GC swappable so we'd be able to use mttk GCs with MRI. A…
I’m curious why you think constraints are such a problem? I’ve worked on quite a few large rails apps, and whilst you’re not wrong, the extra traffic from checking constraints has always been a tiny negligible part of overall db traffic.
It takes two seconds to add a “validated uniqueness” and now for every save or update instead of one SQL command to commit the data you’ve got 2 (multiplied by the number of validations). Plus this validation is weak in that it cannot protect from actual duplicate data. These check queries are individually fast but put a tremendous load on a running app’s database. If you halve the number of queries the database has…
I guess I’ve just never seen the combination of lots of writes AND lots of validates_uniqueness(or whatever db validation) AND the writes are updating the unique fields (due to dirty attributes / partial updates). So it’s never really been an issue.
If that’s been a problem for you I totally believe you, and everything you say about a fix all makes sense.
I used to work with Ruby and Rails and I really found Ruby to be a very comfortable, terse, and expressive language, but I found it very slow after trying some compiled languages (I think I compared service startup and some simple computationally heavy stuff like Advent of Code or Project Euler solutions) and I just couldn’t go back to Ruby after that. Also I found the Rails (framework) stacktraces and source code ve…
In my experience most Ruby apps (Rails in particular) develop this idea that Ruby is the bottleneck when in reality most of the time it's something else entirely (mostly DB or network IO). Of course you found compiled languages faster! that's by definition. You also tried Ruby on CPU sensitive code bases ("Advent of Code or Project Euler solutions"), that's textbook "ruby is slower than C". Rails pays dividends in th…
Weird, because if anything I keep hearing people say Ruby performance and GVL don't matter because it's all IO anyway.
Which is true to a certain extent only. When you first start optimizing a Rails app, it's true that bad queries and N+1 is where most time is wasted, but from my experience once you clear these out, the IO/CPU ratio really isn't that high, generally in the 40-60% IOs range.
My question is what's next? Without sacrificing (much) memory. We know from TruffleRuby that given enough warmups and lots of memory it could be multiple times faster than CRuby. And compared to Ruby 3.3 YJIT may be 2-3x faster. But it seems the communities as a whole cares a lot about memory usage. We know in order to make JIT more useful we need to move some of the Gems from C to Ruby. But other than that do we hav…
> We know in order to make JIT more useful we need to move some of the Gems from C to Ruby.
Just curious, how well do we know this, e.g., theory, experiments, it's being done, or ?
It takes two seconds to add a “validated uniqueness” and now for every save or update instead of one SQL command to commit the data you’ve got 2 (multiplied by the number of validations). Plus this validation is weak in that it cannot protect from actual duplicate data. These check queries are individually fast but put a tremendous load on a running app’s database. If you halve the number of queries the database has…
I guess I’ve just never seen the combination of lots of writes AND lots of validates_uniqueness(or whatever db validation) AND the writes are updating the unique fields (due to dirty attributes / partial updates). So it’s never really been an issue. If that’s been a problem for you I totally believe you, and everything you say about a fix all makes sense.
My question is what's next? Without sacrificing (much) memory. We know from TruffleRuby that given enough warmups and lots of memory it could be multiple times faster than CRuby. And compared to Ruby 3.3 YJIT may be 2-3x faster. But it seems the communities as a whole cares a lot about memory usage. We know in order to make JIT more useful we need to move some of the Gems from C to Ruby. But other than that do we hav…
I added jemalloc to my rails server and it took avg process mem usage of 1-1.5gb down to 400mb.
In my experience most Ruby apps (Rails in particular) develop this idea that Ruby is the bottleneck when in reality most of the time it's something else entirely (mostly DB or network IO). Of course you found compiled languages faster! that's by definition. You also tried Ruby on CPU sensitive code bases ("Advent of Code or Project Euler solutions"), that's textbook "ruby is slower than C". Rails pays dividends in th…
Weird, because if anything I keep hearing people say Ruby performance and GVL don't matter because it's all IO anyway. Which is true to a certain extent only. When you first start optimizing a Rails app, it's true that bad queries and N+1 is where most time is wasted, but from my experience once you clear these out, the IO/CPU ratio really isn't that high, generally in the 40-60% IOs range.
I didn't mean to say it's all IO, that would be wrong. Rails is feature-rich, ActiveRecord for instance spends plenty of time in the CPU (manipulating its internal state). But the idea that Rails/Ruby is slow is outdated and does not jive with any monitoring and metrics we collected even in extremely busy environments. Of course one would gain some percentage of speed if say your backend is some compiled language, but that would mean possibly slower development cycles, hiring, and so on. Billion dollar companies run Rails, and, crucially, show relentless speed in execution (for instance, Stripe). If anything, Rails has the strongest case yet for performance / feature set.
I guess I’ve just never seen the combination of lots of writes AND lots of validates_uniqueness(or whatever db validation) AND the writes are updating the unique fields (due to dirty attributes / partial updates). So it’s never really been an issue. If that’s been a problem for you I totally believe you, and everything you say about a fix all makes sense.
I work at Heroku and see a lot of different apps.
That makes sense! Sorry, you said that but I didnt connect the dots
I get the need to improve Ruby's speed and memory usage, but there's much to be desired. I really enjoy Rails and Ruby in general, but the performance is terrible. I'd like to see how Ruby 3.3 stacks up to other languages and runtimes.
In 2023 if performance is a functional requirement, Ruby is still not the answer IMO. For companies like Shopify, there's really no other alternative at this point, but their "fast" is only fast compared to the performance they've had 1-2 years ago.
Exactly, ruby performance is like someone beating their personal best time jogging around the neighborhood and then writing an article about it. It's something positive in their own ecosystem, but is not competitive when people need results.