What makes ruby slow

I recall Shopify hired a dev who works on a project, FaastRuby, written in Crystal language for their web app. I guarantee the tradeoffs matter to them. Probably helps that Tobias also codes, not to mention contributed to Rails quite a bit.

Thaxll on May 14, root parent prev next [—]. Shopify is actually replacing slow ruby code with Go. And yes they ACK that Ruby is too slow. Also Shopify is a big monolith so it does not help.

A monolith doesn't necessarily mean slower, even with Ruby. There are lots of opportunities to run less code on each request, do some work with the db, and to split off measure bottlenecks into services in a faster language. It's often good to build things quickly, find fit, and then carefully measure before you introduce calls over the network. Thaxll on May 14, root parent next [—].

A monolith is a problem which they are also breaking down, when you want to make something faster it's easier to target the service that does it vs the giant app. Edit: getting downvoted by people that don't work at Shopify. I work at Shopify. I can confirm that what you are saying is totally false. Lol none of these statements are true. Stop painting ruby as slow.

In benchmarks i've seen it's handily beat out PHP, which still runs much of the web. The Rails performance issue has been massively overblown since 1. I don't know about that exact stack, but I know that's the case for Node, for instance. The web server is written in C.

Now, that is not a bad thing. It is a valid result, in the sense that it is a good thing for environments to have fast web servers, and nobody cares what the implementation language is You can't claim "Scripting Language X is fast because it has a fast webserver!

A moment's perusal didn't show me what this particular web server is implemented in. If someone can link me to that web server and show it's implemented in Ruby, I'll be happy to eat my words here. But if the performance is comparable to Go, that's enough evidence it isn't written in Ruby to satisfy me until more evidence comes in. If Ruby isn't a slow language, you've defined "slow language" to the point that no language is slow.

There isn't much competition in the "slower than Ruby" field; Perl 6 is pretty much the only entrant I know of. There's a number of languages as slow as Ruby, it is not uniquely slow, but there's almost nothing slower. PostgreSQL is obviously not written in ruby, but the other components are very much "ruby code". A comparable Node program does 34k requests per second with a rather erratic max latency between 2 and milliseconds.

We have resisted the urge to add native HTTP server bindings to Deno, because we want to optimize the TCP socket layer, and more generally the op interface. Also: not sure how long ago you tried using Perl 6 and found it slow. If your data is from the Parrot days, it is definitely out of date: the MoarVM backend is at least two orders of magnitude faster.

While Raku is generally slower than other languages, there are times when it is is faster than those same languages. The MoarVM backend doesn't generally do either of those things.

Not sure how "overblown" the performance issue is. I rewrote two commercial Rails apps to Phoenix and had both versions of both apps run side by side for two months. The Phoenix apps consumed 7xx less RAM, accomodated 9xx more users on identical hosting instance, and had almost 10x quicker response time. Phoenix is written in Elixir -- another dynamic language. I am willing to argue with facts but you just added another non-factual opinion to the pile.

Oh, and a Mario game implementation says nothing about the typical production uses of a language and its stack. That, plus the fact that most Ruby users don't go for Sinatra and Sequel.

I'm not interested in arguing with someone who doesn't respect others opinions, nor did I make baseless claims: I cited resources. It's true, the mario runthrough was in pure ruby and not rails, and that rails has a slower performance vs.

Performance metrics are not opinions. Ruby is slower than php. I've seen conflicting benchmarks on this showing different results - possibly has changed over time, or run different comparisons. What you linked seems current at least. Ruby ; have been left in the dust by the front-runners eg Node. Perl used to be king a long time ago, eventually, PHP took pole position, and maybe now it's Ruby's time to shine.

But being leader of that particular pack could mean you're nevertheless still 'slow' depending on context.

I wouldn't put node in with luajit. Luajit is about 4x faster than v8 JavaScript. So it's still in the slow category.

Depends on the benchmark. Eg at the bottom of this page [1] can be found a simple fib 40 comparison of a few runtimes. The Node time is at 2. No, both your post and this reply are dogmatic. As I said, Ruby is the slowest modern dynamic programming language and it's much slower than Perl.

I really wish the Ruby community would listen to valid criticism. All dynamic languages are deeply flawed in some way, especially Ruby, and most ecosystems are open to learning from others. You don't have to like dynamic languages - but that doesn't mean they are deeply flawed. The same could be said for statically typed languages with a different set of values. People used to think JavaScript was too dynamic to optimize, too.

Then people poured time and effort into it and now good JavaScript virtual machines can hold their own against competing implementations for other languages. While still not being multicore. I feel that those efforts you mention don't go far enough. And I am pretty sure backwards compatibility will continue dragging JS down for quite a long time still as well.

Surely they are, via workers and worklets. We 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! In my simple relative comparisons of a couple of sample programs, I've found Ruby to be about as fast as, or faster than, Python, and slower than JS.

Ruby and Python, for a long time, have been almost identical in laguage benchmarks and Python's lack of speed hasn't stopped it being the most adopted language by some metrics. So this whole speed thing is a red herring. Tuby is almost the only language which has a really really good, clear and well thoughout standard library. Ruby ofc.

We have it able to run one major app, but still working on making it as fast as we'd like. AndyMaleh on May 21, root parent next [—]. 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. Knowing trade-offs and choosing the right tool for the job, not denying them or trying to fight them like TruffleRuby idiotically does.

The only reason they are profiting is because they have a simple business idea despite their mediocre engineering skills. They use truffle for some plain Ruby stuff. Not running most Rails applications is true, but the applications that can be run on TruffleRuby are not quite plain. Yeah, of course I was generalizing a bit. That blog post is super informative, thanks!

Any performance benchmarck of jruby vs truffleruby vs ruby? Nice, JIT in 2. Wow, there are a lot of them! IfOnlyYouKnew on May 14, parent next [—]. Crystal's performance is simply amazing——not just in comparison with ruby, I recently noticed some Python data-ingestion script was on course to take 12 hours to finish. I spent 30 minutes reimplementing it in Crystal, and it took 7 more minutes until it was done!

That was probably a particularly lopsided comparison: lots of CSV and JSON reading, string-mangling, and writing back; it was using Python stdlib functions only, and numpy and similar would have also helped enormously.

But I do regularly get factor x with all sorts of tasks compared to ruby of python. That said, Ruby's console or Pry is without equivalent in Crystal, and I tend to do most everything on the cli in it. And, as someone already pointed out, the compile cycle is too slow. And the currently existing frameworks are still far away from the ease of whipping up an interface to whatever data you have lying around that Rails offers.

Crystal is not even 1. Because 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. The 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. Ended up using Kemal which is like Sinatra and nowhere like Rails. Yeah 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. There is always Common Lisp Honestly I thought this article would be one line: "Rewrite everything to something else. Basically do not use Ruby. Yes, Ruby is meant to be easy and magical, but it was never meant to be fast. It's fast enough for most things, but you also wouldn't show up to a drag race with a tuned bicycle.

Blazing fast. Is it more native code libraries? Could Ruby follow this path as effectively? And yes, everything that does heavy lifting has native extensions underneath. Most of the production Python code is not actually Python; the language itself is often a proxy to C libraries with a pleasing syntax.

I don't know how it compares to Ruby though. Is Python is able to do so many things quickly? Are the Python web frameworks that much faster? I wasn't specifically thinking web frameworks but a number of projects that I found surprising and performant. One example I can recall is Graphite Whisper, Carbon.

StreamBright on May 14, prev next [—]. Seriously, 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. Same 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. Rewrite in almost anything else and you'll have fast code. But for them it makes sense. 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 on May 14, parent [—]. Stuff 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.

I 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".

Hacker News new past comments ask show jobs submit. How to Fix Slow Code in Ruby shopify. BubRoss on May 14, root parent prev next [—] What speed gains do you get? BubRoss on May 14, root parent next [—] Telling people not to do something is very acceptable in a company. Thaxll on May 14, root parent prev next [—] Shopify is actually replacing slow ruby code with Go.

Thaxll on May 14, root parent next [—] A monolith is a problem which they are also breaking down, when you want to make something faster it's easier to target the service that does it vs the giant app. AndyMaleh on May 21, root parent next [—] Idiotic. IfOnlyYouKnew on May 14, parent next [—] Crystal's performance is simply amazing——not just in comparison with ruby, I recently noticed some Python data-ingestion script was on course to take 12 hours to finish.

StreamBright on May 14, prev next [—] Seriously, if you need high performance out of the box, you should probably just skip Ruby. The memory profiler collects data such as Garbage Collection GC statistics, number of allocations, etc.

It contains a Rack-only middleware that supports call-stack profiling for web requests. In addition to that, block level profiling is also available to any Ruby application. These profiles can be stored in a configurable storage backend such as Google Cloud Storage, and can be visualized through a configurable viewer such as Speedscope , a browser-based flamegraph viewer.

At Shopify, we collect performance profiles in our production environments. Rack Mini Profiler is a great gem, but it comes with a lot of extra features such as database and memory profiling, and it seemed too heavy for our use case. As a result, we built App Profiler that similarly uses Stackprof under the hood. Currently, this gem is used to support our on-demand remote profiling infrastructure for production requests. An example of a performance problem that was identified in production was related to unnecessary GC cycles.

Last year, we noticed that a cart item with a very large quantity used a ridiculous amount of CPU time and resulted in slow requests. It turns out, the issue was related to Ruby allocating too many objects, triggering the GC multiple times.

The figure below illustrates a section of the flamegraph for a similar slow request, and the section corresponds to approximately ms of CPU time. The highlighted chunks correspond to the GC operations, and they interleave with the regular operations.

We inferred that we were allocating too many Ruby objects. Now that we know how to identify performance problems, how do we fix them? Benchmarking helps us prove performance differences in two or more different code paths.

Benchmarking is a way of measuring the performance of code. This code snippet is benchmarking at its simplest. We could extend the example to measure a series of methods, a complex math equation, or anything else that fits into a block. This kind of instrumentation is useful because it can unveil regression or improvement in speed over time. The bm method shows a more detailed breakdown of timing measurements. User, system, and total are all different measurements of CPU time.

User refers to time spent working in user space. Similarly, system denotes time spent working in kernel space. Total is the sum of CPU timings, and real is the same wall time measurement we saw from Benchmark.

What about bmbm? Well, it is exactly the same as bm with one unique difference. The rehearsal, or warmup step is what makes bmbm useful. Add a comment. Active Oldest Votes. Why is Ruby considered slow? Because if you run typical benchmarks between Ruby and other languages, Ruby loses.

What are your options as a Ruby programmer if you want to deal with this "slowness"? Most folks are waiting for Ruby 1. I myself am waiting for Rails 3.

Improve this answer. Thanks, I like the analogy about the signal processing app. It's easier to see what people are talking about now after all these helpful answers. Yes, you were a couple of years away from ruby 2, Ruby 2. My experience from using Ruby 2. Languages aren't slow or fast, their implementations, interpreters and compilers are : — Zelphir Kaltstahl.

ZelphirKaltstahl I am late to this thread, but I would like to comment on your comment : I agree interpreters and compilers play a major role on how a program performs, but the language is very important too. Dynamic languages like Ruby and Python are slower than static typed languages simply because they require lots of type checking at runtime.

Monkey patching is cool, but it is expensive. Python3 within the same order of magnitude Ruby 1. PHP within the same order of magnitude Ruby 1. Java 6 server up to two orders of magnitude slower! C gcc up to two orders of magnitude slower! Depends on whom you ask. You could be told that: Ruby is an interpreted language and interpreted languages will tend to be slower than compiled ones Ruby uses garbage collection though C , which also uses garbage collection, comes out two orders of magnitude ahead of Ruby, Python, PHP etc.

Write for scalability and throw more hardware at it e. Garbage collection itself is not necessarily slow, but the MRI's garbage collection is. I updated the links, but they will in turn become out-of-date in a few months. Is that difference insignificant?

I know that I will not notice the difference between 7ms and 69ms rendering time esp. Can you notice that difference? Show 6 more comments. I disagree with the 'throwing more hardware at it' is cheaper. It's hard to convince customers that they should pay more money for hosting every X months because their platform was designed for developers in mind. Keven: surely development costs would be reduced? Otherwise what would be the point of using Ruby in the first place?

Kevin That statement is a bit broad. Realistically though, you usually need to have a lot more traffic to begin with and increase that by an order of magnitude, before the old hardware can't cope anymore. At that point the topic moves into "a good problem to have" territory and hardly anybody would complain about upgrading hardware. Also, no "customer" runs such a high traffic website without being aware of these kinds of things. Kevin - let's turn that around.

Besides, picking a fast language from the outset is, for many applications, a premature optimization. The chances are that your bottleneck will be somewhere else: database reads, network latency, etc. Show 1 more comment. President James K. GregS: execution performance is always an issue if it impacts usability.

True, scanning an xml file for a string in one second or three doesn't matter from a pure numbers point of view, but a couple seconds difference can make a big difference in usability when you're talking about a user-facing application. Bryan: Agreed, but I stand by my "very rarely" qualification. In Ruby, everything or almost everything is an object. But this characteristic is also one cause of poor Ruby performance. Programs need extra memory to represent data—even primitives like integers—as objects.

It also has to stop the application during garbage collection. Double performance penalty! Reading an entire file at once can take a heavy toll on memory. And why is that? Simple: more often than not, reading the file is just the first step.

This will inevitably lead to the creation of additional objects, which takes more memory and exerts even more pressure on the GC. This is a silly example, but should suffice for our needs. The code loads the whole file to memory. Then we retrieve the last part of the result—which refers to the year—and convert it to an integer number. The code itself is simple, right?

But think about it: why do we need to load the whole file in the memory before starting the process? Even this version still has room for further Ruby performance tuning, but that can be an exercise for the reader. You already know Ruby, because of its design, allocates more memory. To overcome this important roadblock to better Ruby performance, we must use strategies to save as much memory as possible.

One strategy at your disposal amounts to changing objects in place. One version returns a new object with the desired modification, keeping the original object unchanged. The other version changes the original object, thus avoiding the extra memory allocation. The method that changes the original object usually has the same name as the version that returns, plus an exclamation mark.