3 ms·
> But it seems the communities as a whole cares a lot about memory usage. Matz very much sees Ruby as still a general purpose language that still supports scri
by schneems 3y ago
> But it seems the communities as a whole cares a lot about memory usage.
Matz very much sees Ruby as still a general purpose language that still supports scripting as a first tier concern. From that vantage bootup and memory are hugely important. Also providers like Heroku (I work there) charge for memory and the primary way to get parallelism with the GIL/GVL is using multiple processes where memory use can multiply rapidly (literally).
> speed up Ruby on Rails?
You can look at other communities to get a preview of what might come. Ruby now has “object shapes” like node.js which will benefit the community more once people start using it, enabling warnings and fixing hotspots where instance variables are not declared optimally.
Personally, I would like to see rails embrace the power of database backed constraints and fallback to using validation queries only when the database throws an error on commit. You can already saturate a CPU with processes and threads, the biggest bottleneck (IMHO) for most rails apps is still the database. Counterintuitively, pushing those constraints to the database can mean a net decrease in DB computing needed and more overall throughput.
Aside from that I think JIT will help do more with fewer resources. Which makes sense when the main YJIT sponsor has a huge server bill and being able to slash it in half more than justifies such long term gambles.
- dalyons 3y agoI’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.
- schneems 3y agoIt 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 to process you’ll see more resources to process the slow queries in addition to each commit being faster. It ultimately depends on the read/write patterns of the app, but most non-trivial rails apps do a bunch of writing AND reading. My suggestion is less a “this will change the world forever” and more a “fairly clear win, we just have to do it”. In a prior life I talked Sgrif into implementing it before David caused them to drop Active Record maintenance work. I know the broad strokes but don’t have the need or mandate to implement it, plus the active record internals are pretty gnarly. Tons of modules, very little encapsulation. Very hard to know the correct place to put stuff, so stuff goes wherever. It’s gotten better from some of the work of Yehudah, Aaron, and Sage but AFAIK there’s no one on core who wants to own it right now. Eileen has done a lot of work recently, but I don’t think it’s her primary focus.
- byroot 3y ago> but AFAIK there’s no one on core who wants to own it right now. Active Record is probably the "most owned" part of Rails, that's the one with the most core members and committers with deep knowledge of it. As for your feature request, there's https://github.com/Shopify/activerecord-rescue_from_duplicate https://github.com/Shopify/activerecord-rescue_from_duplicat..., and we'd like to attempt to upstream that capability in Rails next year (but as everything it may or may not happen).
- dalyons 3y agoI 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.