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

How to Fix Slow Code in Ruby

engineering.shopify.com

Post reply on HN
Print view View original

61–70 of 213 posts

Re: How to Fix Slow Code in Ruby

#61

Post by pdimitar »

joelbluminator wrote: post #29
dijit wrote: post #17

Earlier quoted context omitted.

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…

> 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?

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?

Re: How to Fix Slow Code in Ruby

#63

Post by chrisseaton »

alberth wrote: post #58
chrisseaton wrote: post #44

Earlier quoted context omitted.

Compatibility yeah I don't think there's any reason we can't be very close to 100% there. For parts of the Ruby ecosystem running production workloads, such as the Liquid template engine, I see 6x performance today. I think that's a realistic goal in time.

Wow, that's amazing! Any rough estimates on when the masses will be able to run RoR on TruffleRuby? (Just order of magnitude timing ... e.g. late 2020, mid 2021, etc.)

If people are motivated to help TruffleRuby then the best thing they can do is test the specs and performance of their gems.

If people have Sinatra apps or similar they could also try those now.

I'm in the GraalVM Slack - https://www.graalvm.org/community/ - ask me for help.

Don't want to speculate more than that.

Re: How to Fix Slow Code in Ruby

#64

Post by pdimitar »

mindfulmore wrote: post #12
stevebmark wrote: post #7

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 hund…

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 productiv…

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

Re: How to Fix Slow Code in Ruby

#65

Post by pdimitar »

saagarjha wrote: post #26
stevebmark wrote: post #7

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 hund…

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.

Re: How to Fix Slow Code in Ruby

#66

Post by tekstar »

Thaxll wrote: post #36
FanaHOVA wrote: post #11

Earlier quoted context omitted.

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

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.

Lol none of these statements are true

Re: How to Fix Slow Code in Ruby

#67

Post by hobofan »

karmakaze wrote: post #62
donretag wrote: post #43

Earlier quoted context omitted.

Basically do not use Ruby

How 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?

In 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.

Re: How to Fix Slow Code in Ruby

#68

Post by pdimitar »

meesterdude wrote: post #21
stevebmark wrote: post #7

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 hund…

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-perfo... additionally: > Sinatra + Sequel is already very competitive in web performance with Go > Between Ruby 1.8 and…

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 7x-11x less RAM, accomodated 9x-10x 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.

Re: How to Fix Slow Code in Ruby

#70

Post by pdimitar »

StreamBright wrote: post #69

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.

Post reply on HN