4 ms·

Well, Shopify is investing in optimizing Ruby, so they believe Ruby was the component with the most opportunity for improvement. And the results are showing the

Well, Shopify is investing in optimizing Ruby, so they believe Ruby was the component with the most opportunity for improvement. And the results are showing there was indeed lots of places where improvements could be made.

elif 3y ago
That's like saying the leading F1 team is investing in optimizing side mirrors, therefore they believe side mirrors are the component with the most opportunity for improvement. The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. The "weakest link" belief is pure conjecture
- pmontra 3y ago
  I understand that it's a metaphor but F1 teams did really optimize side mirrors more than once, leading to controversies Mercedes 2022 https://www.the-race.com/formula-1/mercedes-2022-f1-car-makes-ferrari-fear-spaceship-mirrors/ https://www.the-race.com/formula-1/mercedes-2022-f1-car-make... Williams 2019 https://www.autosport.com/f1/news/williams-modifying-front-suspension-and-mirrors-to-ensure-legality-5280436/5280436/ https://www.autosport.com/f1/news/williams-modifying-front-s... Ferrari 2018 https://www.autosport.com/f1/news/how-ferraris-formula-1-mirrors-became-a-talking-point-5320415/5320415/ https://www.autosport.com/f1/news/how-ferraris-formula-1-mir...
  - elif 3y ago
    Of course, most teams do. Some teams have had 2 revisions to side mirrors this season.. and of course it didn't decide the WC, which is my point. Organizations don't merely optimize "the bottleneck" they optimize everything worth optimizing.
- alberth 3y ago
  No one disputes that Ruby is slow. But you picking “mirrors” in your analogy makes it sounds like a premature optimization. The reason why perf isn’t typically an issue with Rails is the design pattern is to leverage heavy caching. The use of caching is to address the slowness of Ruby.
  - lloeki 3y ago
    The two major areas where caching is used in Rails are: - database queries - template rendering First one because round trip to db + running the query + allocating ORM result objects that otherwise get thrown away. Second one because allocating a ton of strings that get join'd and thrown away. > No one disputes that Ruby is slow. I am, because the blanket statement doesn't make sense without context. Also that view is largely biased by the typical assumption that Ruby == Rails.
    - alberth 3y ago
      > "Also that view is largely biased by the typical assumption that Ruby == Rails." Given that the predominate / vast majority use case for Ruby is for web development and Rails being the dominate Ruby web framework ... it's a fair assumption & characterization for people to make that the Ruby == Rails use case.
    - karmakaze 3y ago
      Well objectively, one could say both Ruby and RoR are slow. The first via The Computer Language Benchmarks Game[0], and the latter via TechEmpower Web Frameworks Benchmarks[1]. In practice though the database is doing most of the work, most of the time so is typically slower than both. [0] https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game https://en.wikipedia.org/wiki/The_Computer_Language_Benchmar... [1] https://www.techempower.com/benchmarks https://www.techempower.com/benchmarks
    - igouy 3y ago
      Ruby without Rails — https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- cowsandmilk 3y ago
  > The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. Most companies don’t have unlimited budgets. Performance-oriented organizations profile and then spend money where profiling tells them to. Shopify isn’t hiring people to contribute to MySQL or Redis internals. They hired a full team to work on Ruby internals, not just creating YJIT, but also on CRuby’s memory layout, hiring the lead on TruffleRuby, and funding academic programming language research on Ruby. No company has an infinite budget to “optimize everything”. It is clear where internal performance testing pointed Shopify (at Ruby) and with double digit gains being extracted year after year, their profiling didn’t lie. And other Ruby on Rails shops are seeing similar double digit performance wins, not on fake benchmarks, but on actual page load times and traffic that can be handled by a server.
  - byroot 3y ago
    Disclaimer: I'm a member of the Ruby & Rails infrastructure team at Shopify and Ruby committer. > Shopify isn’t hiring people to contribute to MySQL or Redis internals You are not wrong, but the main reason is that contrary to Ruby, MySQL and Redis are used by a lot of huge companies and are themselves owned by companies with full time people on it. In comparison Ruby is still mostly a volunteer ran project that receive little funding and effort relative to its importance. As for why trying to make Ruby faster at all in the first place. It's not because it was too slow, it's mostly just that at our scale, the engineering time spent on optimizing the runtime pretty much pays for itself. But that's nothing specific to Ruby, in most very large software companies you will find similar efforts. e.g. I remember Twitter had a team working on the JVM, etc.
    - Justsignedup 3y ago
      thank you for that insight! If I had to guess, early on shopify had a choice to say jump to Java or a JVM-based language and scrap Ruby altogether, but they chose that the benefits of ruby outweigh the benefits of java's performance. So now given that shopify is large enough spending $1MM to win $5MM on infrastructure yearly is easily worth it. In any case, I am very grateful to Shopify because I think if they decided to switch over to java back in the day, ruby may actually be a mostly dead language by now.
- fiedzia 3y ago
  It's easy to believe (and probably true) that there are some low-hanging fruits in a place nobody looked at before.

elif 3y ago

That's like saying the leading F1 team is investing in optimizing side mirrors, therefore they believe side mirrors are the component with the most opportunity for improvement. The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. The "weakest link" belief is pure conjecture

pmontra 3y ago
I understand that it's a metaphor but F1 teams did really optimize side mirrors more than once, leading to controversies Mercedes 2022 https://www.the-race.com/formula-1/mercedes-2022-f1-car-makes-ferrari-fear-spaceship-mirrors/ https://www.the-race.com/formula-1/mercedes-2022-f1-car-make... Williams 2019 https://www.autosport.com/f1/news/williams-modifying-front-suspension-and-mirrors-to-ensure-legality-5280436/5280436/ https://www.autosport.com/f1/news/williams-modifying-front-s... Ferrari 2018 https://www.autosport.com/f1/news/how-ferraris-formula-1-mirrors-became-a-talking-point-5320415/5320415/ https://www.autosport.com/f1/news/how-ferraris-formula-1-mir...
- elif 3y ago
  Of course, most teams do. Some teams have had 2 revisions to side mirrors this season.. and of course it didn't decide the WC, which is my point. Organizations don't merely optimize "the bottleneck" they optimize everything worth optimizing.
alberth 3y ago
No one disputes that Ruby is slow. But you picking “mirrors” in your analogy makes it sounds like a premature optimization. The reason why perf isn’t typically an issue with Rails is the design pattern is to leverage heavy caching. The use of caching is to address the slowness of Ruby.
- lloeki 3y ago
  The two major areas where caching is used in Rails are: - database queries - template rendering First one because round trip to db + running the query + allocating ORM result objects that otherwise get thrown away. Second one because allocating a ton of strings that get join'd and thrown away. > No one disputes that Ruby is slow. I am, because the blanket statement doesn't make sense without context. Also that view is largely biased by the typical assumption that Ruby == Rails.
  - alberth 3y ago
    > "Also that view is largely biased by the typical assumption that Ruby == Rails." Given that the predominate / vast majority use case for Ruby is for web development and Rails being the dominate Ruby web framework ... it's a fair assumption & characterization for people to make that the Ruby == Rails use case.
  - karmakaze 3y ago
    Well objectively, one could say both Ruby and RoR are slow. The first via The Computer Language Benchmarks Game[0], and the latter via TechEmpower Web Frameworks Benchmarks[1]. In practice though the database is doing most of the work, most of the time so is typically slower than both. [0] https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game https://en.wikipedia.org/wiki/The_Computer_Language_Benchmar... [1] https://www.techempower.com/benchmarks https://www.techempower.com/benchmarks
  - igouy 3y ago
    Ruby without Rails — https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
cowsandmilk 3y ago
> The fact is that performance oriented organizations optimize everything unless they have math telling them it isn't worth optimizing. Most companies don’t have unlimited budgets. Performance-oriented organizations profile and then spend money where profiling tells them to. Shopify isn’t hiring people to contribute to MySQL or Redis internals. They hired a full team to work on Ruby internals, not just creating YJIT, but also on CRuby’s memory layout, hiring the lead on TruffleRuby, and funding academic programming language research on Ruby. No company has an infinite budget to “optimize everything”. It is clear where internal performance testing pointed Shopify (at Ruby) and with double digit gains being extracted year after year, their profiling didn’t lie. And other Ruby on Rails shops are seeing similar double digit performance wins, not on fake benchmarks, but on actual page load times and traffic that can be handled by a server.
- byroot 3y ago
  Disclaimer: I'm a member of the Ruby & Rails infrastructure team at Shopify and Ruby committer. > Shopify isn’t hiring people to contribute to MySQL or Redis internals You are not wrong, but the main reason is that contrary to Ruby, MySQL and Redis are used by a lot of huge companies and are themselves owned by companies with full time people on it. In comparison Ruby is still mostly a volunteer ran project that receive little funding and effort relative to its importance. As for why trying to make Ruby faster at all in the first place. It's not because it was too slow, it's mostly just that at our scale, the engineering time spent on optimizing the runtime pretty much pays for itself. But that's nothing specific to Ruby, in most very large software companies you will find similar efforts. e.g. I remember Twitter had a team working on the JVM, etc.
  - Justsignedup 3y ago
    thank you for that insight! If I had to guess, early on shopify had a choice to say jump to Java or a JVM-based language and scrap Ruby altogether, but they chose that the benefits of ruby outweigh the benefits of java's performance. So now given that shopify is large enough spending $1MM to win $5MM on infrastructure yearly is easily worth it. In any case, I am very grateful to Shopify because I think if they decided to switch over to java back in the day, ruby may actually be a mostly dead language by now.
fiedzia 3y ago
It's easy to believe (and probably true) that there are some low-hanging fruits in a place nobody looked at before.