Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby might be faster than you think

johnhawthorn.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Ruby might be faster than you think

#11

Post by bullfightonmars »

ao98 wrote: post #7

Honestly it’s been my experience with Ruby that it’s Rails that can potentially be slow. Ruby is quite fast and even has a JIT option. Rails is by design opinionated, and for some cases I’ve found that I’ve had to work extra hard to ensure performance. That means refactoring code in slightly non traditional ways and having a deeper understanding of how Rails works under the hood (esp in the ORM). So if you think you…

It’s not even that rails is necessarily slow, it’s more the way you use it that is slow. If you tie all your businesses logic to the database and commit complicated changes in transactions, sure it will be terribly slow.

Re: Ruby might be faster than you think

#12

Post by irjustin »

wrs wrote: post #9
throwaway_62022 wrote: post #2

>The Ruby implementation has a subtle mistake which causes signficantly more work than it needs to. To be fair, I do not think that is a "mistake" as such. I have written Ruby professionally for 6 years or so and have committed to several Ruby open source projects and haven't seen an innocus `nil` sitting at the end of a loop, to prevent array allocation. The argument would be fair, if it wasn't idiomatic Ruby. More…

I don’t think there’s any language, interpreted or otherwise, with the goal that knowing its internals won’t help you gain more performance. I mean, that would be nearly impossible. Ruby code, perhaps more than most code, is written for readability and “beauty”. It’s a part of Ruby culture that I greatly appreciate. But if you care about performance, you will act differently, regardless of language. And the whole poi…

That's an interesting question, how does the YJIT perform using the original code? Does it find the optimizations that it results in the same gain such that you don't actually need to personally know the optimization?

Re: Ruby might be faster than you think

#15

Post by WhatIsAModel »

throwaway_62022 wrote: post #2

>The Ruby implementation has a subtle mistake which causes signficantly more work than it needs to. To be fair, I do not think that is a "mistake" as such. I have written Ruby professionally for 6 years or so and have committed to several Ruby open source projects and haven't seen an innocus `nil` sitting at the end of a loop, to prevent array allocation. The argument would be fair, if it wasn't idiomatic Ruby. More…

How are there companies with Ruby source code making enough money to hire full time Ruby devs?

Re: Ruby might be faster than you think

#16

Post by Runways »

cjen wrote: post #5

YJIT and Ruby 3.3 have really impressed me as well. Their VM engineers are clearly doing something right. Related to Ruby perf, I still hear folks worried about rails “not being able to scale”. Let me say something controversial (and clearly wrong): Rails is the only framework that has proven it _can_ scale. GitHub, Shopify, AirBnb, Stripe all use rails and have scaled successfully. Very few other frameworks have tha…

>Rails is the only framework that has proven it _can_ scale.

Citation? Seems like a pretty extraordinary claim.

Re: Ruby might be faster than you think

#17

Post by simonw »

WhatIsAModel wrote: post #15
throwaway_62022 wrote: post #2

>The Ruby implementation has a subtle mistake which causes signficantly more work than it needs to. To be fair, I do not think that is a "mistake" as such. I have written Ruby professionally for 6 years or so and have committed to several Ruby open source projects and haven't seen an innocus `nil` sitting at the end of a loop, to prevent array allocation. The argument would be fair, if it wasn't idiomatic Ruby. More…

How are there companies with Ruby source code making enough money to hire full time Ruby devs?

Ask GitHub, Shopify and Stripe.

Re: Ruby might be faster than you think

#18

Post by elif »

wrs wrote: post #9
throwaway_62022 wrote: post #2

>The Ruby implementation has a subtle mistake which causes signficantly more work than it needs to. To be fair, I do not think that is a "mistake" as such. I have written Ruby professionally for 6 years or so and have committed to several Ruby open source projects and haven't seen an innocus `nil` sitting at the end of a loop, to prevent array allocation. The argument would be fair, if it wasn't idiomatic Ruby. More…

I don’t think there’s any language, interpreted or otherwise, with the goal that knowing its internals won’t help you gain more performance. I mean, that would be nearly impossible. Ruby code, perhaps more than most code, is written for readability and “beauty”. It’s a part of Ruby culture that I greatly appreciate. But if you care about performance, you will act differently, regardless of language. And the whole poi…

>I don’t think there’s any language, interpreted or otherwise, with the goal that knowing its internals won’t help you gain more performance.

It is, indeed, a fundamental goal of ruby that there are multiple ways to write the same thing, and that the programmer should not need to understand nuances of the compiler.

"I need to guess how the compiler works. If I'm right, and I'm smart enough, it's no problem. But if I'm not smart enough, and I'm really not, it causes confusion. The result will be unexpected for an ordinary person. This is an example of how orthogonality is bad." -matz 2003.

Re: Ruby might be faster than you think

#19

Post by lolinder »

I found something similar with Java's JIT.

I had a very hot loop (runtime of 15 minutes) that I wanted to speed up. I profiled it over and over again in IntelliJ, identifying every possible allocation I could eliminate. When I was done there were zero allocations in the hot loop and the thing ran something like 4x faster than it had previously.

At that point, looking at the code, I realized that what I had written was very similar to how I'd have implemented it in Rust—I allocated a bunch of structs upfront and then "borrowed" them into the various parts of the algorithm. Since it was so close in style to Rust anyway, I decided to port it over and see if I could get any more performance out of it by being closer to the metal.

It turned out that the difference in performance between the Rust version and the Java version was statistically insignificant. I tried a few different optimization settings but didn't manage to get Rust to be any faster than Java's JIT.

This was eye opening to me. Now that most runtimes have JIT compilers, I suspect that far more important than choosing the right language is deeply understanding how the language you're working with works under the hood so you can eliminate hot spots and unnecessary allocations.

Re: Ruby might be faster than you think

#20

Post by aeze »

Runways wrote: post #16
cjen wrote: post #5

YJIT and Ruby 3.3 have really impressed me as well. Their VM engineers are clearly doing something right. Related to Ruby perf, I still hear folks worried about rails “not being able to scale”. Let me say something controversial (and clearly wrong): Rails is the only framework that has proven it _can_ scale. GitHub, Shopify, AirBnb, Stripe all use rails and have scaled successfully. Very few other frameworks have tha…

>Rails is the only framework that has proven it _can_ scale. Citation? Seems like a pretty extraordinary claim.

It was mentioned in the OP but: GitHub, Shopify, AirBnb, Stripe
Post reply on HN