9 ms·

Benchmarks are subjective, but all benchmarks show Ruby as slower than compared dynamic languages. The relative speed difference is different per benchmark, but

Benchmarks 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 ago
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!
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.
- ryansouza 6y ago
  I guarantee the tradeoffs matter to them
  - sosodev 6y ago
    I’ve seen videos on Twitter of the Shopify CEO saying that Ruby’s performance literally doesn’t matter to them. That it’s easy enough to scale it horizontally and the benefits outweigh the cost.
    - joshmn 6y ago
      Probably helps that Tobias also codes, not to mention contributed to Rails quite a bit.
- todotask 6y ago
  I recall Shopify hired a dev who works on a project, FaastRuby, written in Crystal language for their web app.
- dijit 6y ago
  Pedantry aside, we've reached a point in our industry where we can do a lot with horizontal scalability. I mean, every programmer who funnels through university understands map reduce, and that helps on multi-core threading up to system job running. But there is a limit, usually in the persistence and caching layers. What you'll find is that those "large scale deployments" are going to have a -lot- of internal cache systems and I can pretty much guarantee that the services running those caches and persistence will not be written in ruby. You can make anything* scale, but how many CPU cycles you need to burn to get the functionality you want is a matter for the finance department. If you're running in a lossy business, you can bet that those CPU cycles will begin to cost more than developer velocity is worth, because servers are an eternal and ongoing cost. On the flip side if you make more money than the infra+devs cost, then nobody is going to hound you for wasting 2x 3x the cost. Because "it's the cost of doing business" is easier to justify when you're cash positive.
  - joelbluminator 6y ago
    > services running those caches and persistence will not be written in ruby So what? What's wrong with using software like redis for cache, for a very small (but important) part of your business? I bet java apps use redis as well, and redis isn't written in java. So?
    - pdimitar 6y ago
      Is this an honest question? I honestly can't tell and I am not saying it to show disrespect -- just wondering if you are sarcastic. Erlang/Elixir have built-in caches that respond in the matter of 30-150 nanoseconds. Why would you need an external service for that? It's adding complexity -- and likely hosting costs. Isn't it self-evident to you that adding Redis as a caching layer to your stack is a bandaid to a deeper problem?
      - ronjouch 6y ago
        Interesting but not surprising; I'm being regularly pleasantly surprised by the Erlang/Elixir ecosystem :) . Can you precise what you're talking about when you say "Erlang/Elixir have built-in caches" ? What's the name of the concept and where in the typical stack does it fit? Is this https://blog.appsignal.com/2019/11/12/caching-with-elixir-and-ets.html https://blog.appsignal.com/2019/11/12/caching-with-elixir-an... or something else? Care to share a few link to docs/articles? Thanks.
- Thaxll 6y ago
  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.
  - ch4s3 6y ago
    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 6y ago
      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.
      - byroot 6y ago
        I work at Shopify. I can confirm that what you are saying is totally false.
  - tekstar 6y ago
    Lol none of these statements are true
- pdimitar 6y ago
  > Phew, I'm glad GitHub and Shopify's scale is still small. Phew, good thing they can afford to burn a lot of cash for hosting.
  - tim333 6y ago
    I guess that's so though it's interesting in the early days Github didn't: >...a web startup like ours doesn’t need any outside money to succeed. I know this because we haven’t taken a single dime from investors. We bootstrapped the company on a few thousand dollars and became profitable the day we opened to the public and started charging for subscriptions. Tom Preston-Werner in 2008. I guess the thing is not how much the hosting costs in absolute terms but how much it costs relative to what customers are prepared to pay for the service.
    - pdimitar 6y ago
      Once a business grows to certain size and beyond the shareholders don't want to hear anything about tech rewrites. They are happy the product is working, they are not alarmed by slow response times (which GitHub has plenty of on my gigabit connection that streams 4k@30fps without any lag) unless there's a big customer churn, and hosting costs, even if big-ish, to them are just the cost of doing business. My point is, yes, you are right -- but there's a lot of conservatism involved once the business gets to a certain size. Nobody cares about improving anything from then on (which usually leads to the now-giant to start steadily losing relevance; GitHub is quite far from that but we all remember Microsoft, right?).
mindfulmore 6y ago
The article doesn't even discuss benchmarking Ruby against other languages, so I'm not really sure what you're on about. Couldn't resist taking a performance jab at Rails? Also, I'll take "double the hardware specs" if it means I'm actually able to focus on what I'm building and not dicking around with devops or rebuilding all of stuff Rails metaprograms for me by hand. If there was a framework for being as productive as Rails at half the cost then it would be flourishing. There isn't and as a result Rails isn't going anywhere any time soon.
- deleted 6y ago
  [deleted]
- pdimitar 6y ago
  > Also, I'll take "double the hardware specs" if it means I'm actually able to focus on what I'm building and not dicking around with devops or rebuilding all of stuff Rails metaprograms for me by hand. Try 7x to 11x. That's the amount of reduced RAM usage -- and the amount of increased accommodated users -- on identical hosting by the two apps I rewrote from Rails to Phoenix. > If there was a framework for being as productive as Rails at half the cost then it would be flourishing. Bold of you to assume technical merit is the only factor. Historically this has almost never been true. There are a number of web frameworks that perform much better than Rails and are quite easy to work with. Cargo culting is a powerful force. Corporate inertia -- even more.
  - imhoguy 6y ago
    When my small SaaS customer calls and asks for an extra extension at current hard times, then all I need is to open up Rails production console (pry) and live type in an ad-hoc code with auto-completion aid: $ rails c Loading production environment (Rails 5.2.0) [1] pry(main)> s = Subscriber.find_by_email('xyz@abc.com') => #<Subscriber:0x000055dbb64c3bb8 id: 12913, email: "xyz@abc.com", state: "active", expires_on: Fri, 15 May 2020 14:10:19 UTC +00:00, ... [2] pry(main)> s.expires_on += 2.months => Wed, 15 Jul 2020 14:10:19 UTC +00:00 [3] pry(main)> s.save! => true It is done now! Good luck! Bye! - end of call. Cargo culting? From whom? I don't give a sh*.
meesterdude 6y ago
Stop painting ruby as slow. In benchmarks i've seen it's handily beat out PHP, which still runs much of the web. the ruby 3x3 goal, of getting running super mario at 60FPS, was if i recall correctly, already reached (or close to it) in ruby 2.6. https://developers.redhat.com/blog/2018/03/22/ruby-3x3-performance-goal/ https://developers.redhat.com/blog/2018/03/22/ruby-3x3-perfo... additionally: > Sinatra + Sequel is already very competitive in web performance with Go > Between Ruby 1.8 and 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released. https://news.ycombinator.com/item?id=17220967 https://news.ycombinator.com/item?id=17220967
- wolco 6y ago
  Ruby is slower than php. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php-yarv.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - meesterdude 6y ago
    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.
    - cygx 6y ago
      Also keep in mind that as far as performance of dynamic languages goes, all of the P* languages (Perl, Python, PHP, and... Ruby ;)) have been left in the dust by the front-runners (eg Node.js or LuaJIT). 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.
      - VWWHFSfQ 6y ago
        I wouldn't put node in with luajit. Luajit is about 4x faster than v8 JavaScript. So it's still in the slow category
saagarjha 6y ago
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.
- goatlover 6y ago
  It's interesting because Lars Bak was optimizing Smalltalk and Self VMs in the 90s.
- pdimitar 6y ago
  ...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.
  - pjmlp 6y ago
    Surely they are, via workers and worklets.
  - igouy 6y ago
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-node-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... multicore.
barrkel 6y ago
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.
- cutler 6y ago
  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.
igouy 6y ago
> …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. No & No. https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html#chart-fastest-more https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

gscho 6y ago

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!

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.

ryansouza 6y ago
I guarantee the tradeoffs matter to them
- sosodev 6y ago
  I’ve seen videos on Twitter of the Shopify CEO saying that Ruby’s performance literally doesn’t matter to them. That it’s easy enough to scale it horizontally and the benefits outweigh the cost.
  - joshmn 6y ago
    Probably helps that Tobias also codes, not to mention contributed to Rails quite a bit.
todotask 6y ago
I recall Shopify hired a dev who works on a project, FaastRuby, written in Crystal language for their web app.
dijit 6y ago
Pedantry aside, we've reached a point in our industry where we can do a lot with horizontal scalability. I mean, every programmer who funnels through university understands map reduce, and that helps on multi-core threading up to system job running. But there is a limit, usually in the persistence and caching layers. What you'll find is that those "large scale deployments" are going to have a -lot- of internal cache systems and I can pretty much guarantee that the services running those caches and persistence will not be written in ruby. You can make anything* scale, but how many CPU cycles you need to burn to get the functionality you want is a matter for the finance department. If you're running in a lossy business, you can bet that those CPU cycles will begin to cost more than developer velocity is worth, because servers are an eternal and ongoing cost. On the flip side if you make more money than the infra+devs cost, then nobody is going to hound you for wasting 2x 3x the cost. Because "it's the cost of doing business" is easier to justify when you're cash positive.
- joelbluminator 6y ago
  > services running those caches and persistence will not be written in ruby So what? What's wrong with using software like redis for cache, for a very small (but important) part of your business? I bet java apps use redis as well, and redis isn't written in java. So?
  - pdimitar 6y ago
    Is this an honest question? I honestly can't tell and I am not saying it to show disrespect -- just wondering if you are sarcastic. Erlang/Elixir have built-in caches that respond in the matter of 30-150 nanoseconds. Why would you need an external service for that? It's adding complexity -- and likely hosting costs. Isn't it self-evident to you that adding Redis as a caching layer to your stack is a bandaid to a deeper problem?
    - ronjouch 6y ago
      Interesting but not surprising; I'm being regularly pleasantly surprised by the Erlang/Elixir ecosystem :) . Can you precise what you're talking about when you say "Erlang/Elixir have built-in caches" ? What's the name of the concept and where in the typical stack does it fit? Is this https://blog.appsignal.com/2019/11/12/caching-with-elixir-and-ets.html https://blog.appsignal.com/2019/11/12/caching-with-elixir-an... or something else? Care to share a few link to docs/articles? Thanks.
Thaxll 6y ago
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.
- ch4s3 6y ago
  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 6y ago
    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.
    - byroot 6y ago
      I work at Shopify. I can confirm that what you are saying is totally false.
- tekstar 6y ago
  Lol none of these statements are true
pdimitar 6y ago
> Phew, I'm glad GitHub and Shopify's scale is still small. Phew, good thing they can afford to burn a lot of cash for hosting.
- tim333 6y ago
  I guess that's so though it's interesting in the early days Github didn't: >...a web startup like ours doesn’t need any outside money to succeed. I know this because we haven’t taken a single dime from investors. We bootstrapped the company on a few thousand dollars and became profitable the day we opened to the public and started charging for subscriptions. Tom Preston-Werner in 2008. I guess the thing is not how much the hosting costs in absolute terms but how much it costs relative to what customers are prepared to pay for the service.
  - pdimitar 6y ago
    Once a business grows to certain size and beyond the shareholders don't want to hear anything about tech rewrites. They are happy the product is working, they are not alarmed by slow response times (which GitHub has plenty of on my gigabit connection that streams 4k@30fps without any lag) unless there's a big customer churn, and hosting costs, even if big-ish, to them are just the cost of doing business. My point is, yes, you are right -- but there's a lot of conservatism involved once the business gets to a certain size. Nobody cares about improving anything from then on (which usually leads to the now-giant to start steadily losing relevance; GitHub is quite far from that but we all remember Microsoft, right?).

mindfulmore 6y ago

The article doesn't even discuss benchmarking Ruby against other languages, so I'm not really sure what you're on about. Couldn't resist taking a performance jab at Rails? Also, I'll take "double the hardware specs" if it means I'm actually able to focus on what I'm building and not dicking around with devops or rebuilding all of stuff Rails metaprograms for me by hand. If there was a framework for being as productive as Rails at half the cost then it would be flourishing. There isn't and as a result Rails isn't going anywhere any time soon.

deleted 6y ago
[deleted]
pdimitar 6y ago
> Also, I'll take "double the hardware specs" if it means I'm actually able to focus on what I'm building and not dicking around with devops or rebuilding all of stuff Rails metaprograms for me by hand. Try 7x to 11x. That's the amount of reduced RAM usage -- and the amount of increased accommodated users -- on identical hosting by the two apps I rewrote from Rails to Phoenix. > If there was a framework for being as productive as Rails at half the cost then it would be flourishing. Bold of you to assume technical merit is the only factor. Historically this has almost never been true. There are a number of web frameworks that perform much better than Rails and are quite easy to work with. Cargo culting is a powerful force. Corporate inertia -- even more.
- imhoguy 6y ago
  When my small SaaS customer calls and asks for an extra extension at current hard times, then all I need is to open up Rails production console (pry) and live type in an ad-hoc code with auto-completion aid: $ rails c Loading production environment (Rails 5.2.0) [1] pry(main)> s = Subscriber.find_by_email('xyz@abc.com') => #<Subscriber:0x000055dbb64c3bb8 id: 12913, email: "xyz@abc.com", state: "active", expires_on: Fri, 15 May 2020 14:10:19 UTC +00:00, ... [2] pry(main)> s.expires_on += 2.months => Wed, 15 Jul 2020 14:10:19 UTC +00:00 [3] pry(main)> s.save! => true It is done now! Good luck! Bye! - end of call. Cargo culting? From whom? I don't give a sh*.

meesterdude 6y ago

Stop painting ruby as slow. In benchmarks i've seen it's handily beat out PHP, which still runs much of the web. the ruby 3x3 goal, of getting running super mario at 60FPS, was if i recall correctly, already reached (or close to it) in ruby 2.6. https://developers.redhat.com/blog/2018/03/22/ruby-3x3-performance-goal/ https://developers.redhat.com/blog/2018/03/22/ruby-3x3-perfo... additionally: > Sinatra + Sequel is already very competitive in web performance with Go > Between Ruby 1.8 and 2.5, performance has improved around 13x in tight loops[2]. The Rails performance issue has been massively overblown since 1.9 was released. https://news.ycombinator.com/item?id=17220967 https://news.ycombinator.com/item?id=17220967

wolco 6y ago
Ruby is slower than php. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/php-yarv.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- meesterdude 6y ago
  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.
  - cygx 6y ago
    Also keep in mind that as far as performance of dynamic languages goes, all of the P* languages (Perl, Python, PHP, and... Ruby ;)) have been left in the dust by the front-runners (eg Node.js or LuaJIT). 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.
    - VWWHFSfQ 6y ago
      I wouldn't put node in with luajit. Luajit is about 4x faster than v8 JavaScript. So it's still in the slow category

saagarjha 6y ago

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.

goatlover 6y ago
It's interesting because Lars Bak was optimizing Smalltalk and Self VMs in the 90s.
pdimitar 6y ago
...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.
- pjmlp 6y ago
  Surely they are, via workers and worklets.
- igouy 6y ago
  https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-node-6.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... multicore.

barrkel 6y ago

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.

cutler 6y ago
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.

igouy 6y ago

> …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. No & No. https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html#chart-fastest-more https://benchmarksgame-team.pages.debian.net/benchmarksgame/...