16 ms·
How to Fix Slow Code in Ruby
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- lidHanteyk 6y agoInteresting; Shopify doesn't use TruffleRuby, but instead prefers MRI?
- ch4s3 6y agoTruffleRuby can’t quite run Rails yet. They use truffle for some plain Ruby stuff.
- kipply 6y agoNot running most Rails applications is true, but the applications that can be run on TruffleRuby are not quite plain. It can run a web application that serves storefront traffic (source at the end of https://engineering.shopify.com/blogs/engineering/optimizing-ruby-lazy-initialization-in-truffleruby-with-deoptimization https://engineering.shopify.com/blogs/engineering/optimizing...)
- ch4s3 6y agoYeah, of course I was generalizing a bit. That blog post is super informative, thanks!
- chrisseaton 6y ago> Interesting; Shopify doesn't use TruffleRuby, but instead prefers MRI? Shopify's investing in TruffleRuby as well as MRI - they employ me to work on it. We have it able to run one major app, but still working on making it as fast as we'd like.
- AndyMaleh 6y agoIdiotic. That’s what using the right tool for the job is all about. Ruby isn’t for everything and never will be. Just stick to CRuby (or JRuby if integrating with the JVM). They’re already stable. No point diluting the space with more rubies for superficial reasons like lessening the performance trade off in Ruby when there are many many other languages better suited for high performance algorithms to apply where needed. That’s what good engineering is all about after all. Knowing trade-offs and choosing the right tool for the job, not denying them or trying to fight them like TruffleRuby idiotically does. Shopify is like Canada’s Groupon. The only reason they are profiting is because they have a simple business idea despite their mediocre engineering skills.
- enitihas 6y agoMore interestingly, the TurffleRuby founder works at Shopify IIRC.
- deleted 6y ago[deleted]
- The_rationalist 6y agoAny performance benchmarck of jruby vs truffleruby vs ruby?
- kipply 6y agohttps://github.com/mame/optcarrot https://github.com/mame/optcarrot Includes some rare, bonus ruby implementations too <3
- stevebmark 6y agoBenchmarks are subjective, but all benchmarks show Ruby as slower than compared dynamic languages. The relative speed difference is different per benchmark, but across the board Ruby is slower. It fundamentally has to be slower. Ruby is the most dynamic of the dynamic programming languages. And the community has embraced metaprogramming, making it every more dynamic. Especially on webservers, you'll be executing hundreds, sometimes thousands, more lines of code than other servers, especially in a mature system. Is it "slow" enough to matter? Probably not until you get to a medium scale. Everywhere I've worked, we've had to on average double the hardware specs for Ruby servers to make them as performant as other dynamic language applications we run. Not the most expensive thing in the grand scheme of things, but there are entire cottage industries of magically tuning Ruby and Rails that you don't have to worry about with other systems until much larger scales.
- gscho 6y agoWe can't forget to consider the cost of productivity gains and developer happiness from using ruby. It can significantly out weigh the cost of some additional hardware. If it doesn't bring you that, then we have a problem!
- FanaHOVA 6y ago> Is it "slow" enough to matter? Probably not until you get to a medium scale. Phew, I'm glad GitHub and Shopify's scale is still small.
- alberth 6y agoWhat's current state on GraalVM as it relates to running production Ruby code? From what I understand, it's the fastest VM out there at the moment for Ruby. And yes, it's from Oracle but they have GPL'd the code [2] [1] https://www.graalvm.org https://www.graalvm.org [2] https://www.graalvm.org/docs/faq/ https://www.graalvm.org/docs/faq/ Edit: looks like TruffleRuby is built onto of Graal. https://github.com/oracle/truffleruby https://github.com/oracle/truffleruby
- yxhuvud 6y agoLast time I tried to run Truffle on the company test suite it spent an hour processing 1/8th of the suite. Then it was killed by the OOM killer. On a 32 GB machine. To be fair there was only one or two errors during that, so compatibility is at least getting there. Meanwhile Ruby 2.6.5 chugs along and finishes the whole suite in 8 minutes. Never hitting any unreasonable amounts of memory.
- chrisseaton 6y agoYes TruffleRuby struggles to run test code because it works against the optimisations we add to make production code fast. For example when you add more profiling to better optimise the hot code it makes the cold code slower, and tests are almost all cold code. Also our C extension emulation layer used to be extraordinarily slow while we made it work correctly, and it's still rather slow. It's a challenge but we're working on it. But TruffleRuby is the only alternative Ruby implementation to even run major applications that I've tried at Shopify.
- llamataboot 6y agoI even have a little method in my .pryrc that lets me easily benchmark on the fly in the console def benchmark_time(repetitions = 100, &block) require 'benchmark' Benchmark.bm{ |b| b.report{ repetitions.times(&block) } } end
- sealthedeal 6y agoI wish we could just take Ruby, scrap it, and as a community replace it with Crystal Lang
- technics256 6y agoWhy?
- remmargorp64 6y agoBecause crystal lang has all of the main syntax and features that people love about Ruby, but it's way faster because of the typing and compiling. "Fast as C, slick as ruby"
- karmakaze 6y agoThe compiler would have to dramatically increase in speed to make it effective. I tried using Crystal to build a small app using Amber or Lucky frameworks. They weren't fast enough for a flowing edit/compile/run workflow. Ended up using Kemal which is like Sinatra and nowhere like Rails.
- jbverschoor 6y agoYeah that's the problem I had too. It'd be nice if there's an interpreted and a compiled way of running. Preferrably with hotcode swap
- chrisseaton 6y ago> Because crystal lang has all of the main syntax and features that people love about Ruby Except for one at least massive feature... runtime metaprogramming... on which the entire Rails ecosystem is built.
- goatlover 6y agoThere is always Common Lisp ...
- fxtentacle 6y agoC++ It's that easy :)
- donretag 6y agoBasically do not use Ruby
- karmakaze 6y agoHow is it that Python is able to do so many things quickly (even excluding NumPy/SciPy)? Is it more native code libraries? Could Ruby follow this path as effectively?
- hobofan 6y agoIn general these days, Python "general purpose" code is about as fast/slow as Ruby. And yes, everything that does heavy lifting has native extensions underneath.
- pdimitar 6y agoMost of the production Python code is not actually Python; the language itself is often a proxy to C libraries with a pleasing syntax.
- mwcampbell 6y agoEric Raymond wrote about this, in relation to his reposurgeon project, here: http://esr.ibiblio.org/?p=8161 http://esr.ibiblio.org/?p=8161 Basically, what he found is that for programs that work with large graphs of objects (as opposed to arrays of numbers, which are the domain of numpy and friends), Python isn't all that fast. I don't know how it compares to Ruby though.
- igouy 6y agoIs Python is able to do so many things quickly? https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html#chart-fastest-more https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- pdimitar 6y ago...Rewrite in almost anything else and you'll have fast code. :) It's quite amazing the lengths the companies will go to just to avoid changing their status quo. But for them it makes sense. --- EDIT: Downvoters, calm down. Ruby on Rails is objectively quite a slow framework and this is proven in many public benchmarks (Techempower included). And Ruby isn't the fastest among the dynamic languages either. Less cargo culting and more facts, please.
- BubRoss 6y agoStuff like this always confuses me. It's like asking how to exercise without sweating. I would think the first sign of performance problems would mean some profiling and some porting of sections to a native language. Instead some companies go down a crazy rabbit hole instead of just making some shared libraries.
- pdimitar 6y agoI thought the same as you but then I realized that the investment in a tech stack is basically done only once and almost never revisited. Then people go on all sorts of crazy journeys to justify their investments in pain and burned money. Even though I get downvoted at places in this thread (and upvoted generously on others), I will never tell to people "you should always just rewrite to Elixir". Meh. If your app works fine, have it be in COBOL or PL/1 if that helps you do your job better. But as you said, when your app/hosting starts struggling you should start rethinking your choices if all the lower-hanging fruit has been already collected.
- jbverschoor 6y agoTuby is almost the only language which has a really really good, clear and well thoughout standard library.
- jbverschoor 6y agoRuby ofc
- StreamBright 6y agoSeriously, if you need high performance out of the box, you should probably just skip Ruby. I love that language to death but most of the time you cannot use of it for a decent scale.
- pdimitar 6y agoSame for me with Elixir. I love that little thing so much but there are workloads where it objectively shouldn't be used -- for web apps it's definitely one of the best picks out there but that's a different topic. I've lately been writing several Rust tools and mini apps and have admitted to myself that even if a language stack clicks with you almost perfectly, you should still reach out to other tools when appropriate. Even us the senior devs forget that, and it pays to get reminded of it every now and then.
- lostcolony 6y agoHere's the official reminder not to use the BEAM for all things - http://erlang.org/faq/introduction.html#idp32557584 http://erlang.org/faq/introduction.html#idp32557584
- rdoherty 6y agoFirst thing I tell anyone when they say "this code is slow because of X" is to profile it. Profile, profile, profile! More often than not your assumptions are wrong. There's a myriad of tools out there for profiling, some language specific, some not. Learn at least one of them well, how to read flamegraphs and how to benchmark properly (warmup code, synthetic vs real traffic, etc). There's definitely a jump between making guesses and hoping you improve performance vs truly understanding what your code is doing.
- ykevinator 6y agoSecond this, more often than not
- timwis 6y agoThere’s a much easier way: just increase `Rails.application.speed` from 5 to 10 in the application config.
- praveenperera 6y agoI wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing wildly more performant code.
- pdog 6y agoShopify is an insanely huge e-commerce platform (and a $100B company). I'd say their developers are pretty productive with Ruby on Rails.
- nitsky 6y agoYes, and at the time Shopify was started Ruby was likely a very good choice. The parent comment is saying that today there are alternatives that run faster and provide similar levels of productivity.
- monadic2 6y agoYou’d have to compare them to an equivalent shop in the same market of about the same size with a different stack to get a meaningful answer out of this—I’d say off-hand that it’s very unlikely their edge is tech.
- adventured 6y ago> Shopify is an insanely huge e-commerce platform (and a $100B company). That's an interesting note. They have a $90b market cap, trading at ~53 times sales. It's one of the more extreme valuations I've seen in the last 25 years, including the dotcom bubble (and that's saying something with how overvalued everything cloud-related is today). As one comparison for the absurdity, Yahoo during most of the height of the dotcom bubble, was trading for 30-50 times sales, growing sales faster than Shopify, and they were solidly profitable (Shopify has never earned a consequential profit in its history). That's how bad Shopify's present valuation is, to get good comps you have to reach into the dotcom bubble. The market thinks they're Amazon-like. The problem is they've never demonstrated any great margins in their platform (despite 14 years and counting) and Amazon's big lift-off in their stock occurred solely due to the ability of AWS to generate immense operating income. Without AWS, Amazon eventually gets the sad multiples of a Target or Walmart on their retail business. This is an obviously mistaken valuation riding one of the most overvalued markets in US history, one that will most likely brutalize investors that get in late. It's a classic example of how very inefficient and irrational the stock market can be in the shorter term. And no, that doesn't mean an investor should be the fool to step in front of the irrationality train and short it either (everyone here probably has heard the Keynes line about the market remaining irrational longer than you can remain solvent). It'll take at least 10-15 years at a minimum for Shopify to grow into its present valuation, in the best case scenario, if everything goes perfectly and they some day find some margin in their business. If they eventually manage an enormous $2 billion profit ($1.7b in sales today ttm), they'll still have a 45 PE ratio at today's valuation. That's a prime market example of insanity. eBay has a vastly superior business (in all regards, including its quasi-monopoly positioning and the tremendous profitability of ebay's platform), trading for a huge discount to Shopify, on the basis of the market's mistaken extrapolation about Shopify's future. If they're lucky, they'll one day be the size of eBay with a fraction of the profit margin (and of course eBay has a mere $29b market cap, 12x op income multiple; compression is a killer). I mention eBay (beyond obvious reasons), because Shopify is likely doing nothing more than pulling future returns forward to an extreme, as eBay once did (leading to a decade of stagnation in the stock).
- benkuhn 6y agoReally surprised how many commenters are talking about using a faster language when the example of slow code in the post is failing to cache the results of an expensive database query. In my experience, even in "slow" languages, that type of thing is the predominant source of major performance problems, and the supposedly "slow" language would be perfectly adequate if you an stop shooting yourself in the foot (and if you can't, a faster language will not help you). I'm sure there are extremely high-performance or high-scale points where language choice starts to matter more, but I'm also not surprised if Shopify is correct not to think they're there yet.
- pdimitar 6y agoIt is surprising until you realize that Rails' ActiveRecord consistently wastes 100-200ms on every request just to serialize / deserialize data from/to the database. So yes, a language that's both faster and has less overhead in its ORM / DataMapper library definitely will help you.
- jordanthoms 6y agoOur data-heavy API returns JSON responses from our DB in ~40ms using ActiveRecord. So no, it doesn't waste 100ms on every request! We're serving around 6000 requests like that per second.
- pdimitar 6y agoWell, you likely have a dedicated (or pretty strong) server. The Heroku dynos I've tested with some years ago performed quite horribly. Only a proper Xeon server was able to achieve sub-100ms responses. But hey, if Ruby improved in the meantime, cool.
- toomanybeersies 6y agoRails on Heroku is about the most inefficient combination you can get for a web server. I've always thought of it as the platform you use for running toy apps with maybe a couple of dozen users at most and a low load. It's incredibly quick and easy to get a Rails app running on Heroku, a couple of hours at most. But you pay (in dollars and performance) for this.
- newintellectual 6y agoStop using Ruby?