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

201–210 of 213 posts

Re: How to Fix Slow Code in Ruby

#201

Post by dijit »

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?

My point is that for all the talk of how performance doesn’t matter and that we can scale ruby, the real heavy lifting is not handled by ruby.

It’s not a “problem”, but if you’re going to talk about large companies scaling something you need to understand that they’re likely scaling it in spite of limitations.

Largely, some systems don’t scale too well (latency on network accessible cache, throughput in persistence layers such as databases) so a lot of application layers will lean on those things heavily and they are exclusively written in relatively “faster” languages.

Re: How to Fix Slow Code in Ruby

#202

Post by pdimitar »

jb3689 wrote: post #200
pdimitar wrote: post #198

Earlier quoted context omitted.

But if you are going to override the defaults, then the argument of "Rails is performant out of the box" no longer holds water, does it?

Was that an argument? It seems pretty clear that that is not the goal of Rails. I'm arguing here that "Rails can't be performant" is not necessarily true

Sadly often this is the argument, yes.

I am glad to see that there are much more reasonable Rails devs out there compared to some rather toxic individuals around in HN at least!

A lot of tech can be fine-tuned to be very performant. My point was (still is) that there exist technologies today that allow you to delay your scaling decisions much further in future, compared to what a stock Rails app (without any performance tuning) will.

Re: How to Fix Slow Code in Ruby

#203

Post by pdimitar »

meesterdude wrote: post #189
pdimitar wrote: post #68

Earlier quoted context omitted.

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

> I am willing to argue with facts but you just added another non-factual opinion to the pile. I'm not interested in arguing with someone who doesn't respect others opinions, nor did I make baseless claims: I cited resources. > ...Oh, and a Mario game implementation says nothing about the typical production uses of a language and its stack. It's true, the mario runthrough was in pure ruby and not rails, and that rail…

> I'm not interested in arguing with someone who doesn't respect others opinions, nor did I make baseless claims: I cited resources.

Performance metrics are not opinions.

Re: How to Fix Slow Code in Ruby

#204

Post by igouy »

pdimitar wrote: post #65
saagarjha wrote: post #26

Earlier quoted context omitted.

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.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

multicore.

Re: How to Fix Slow Code in Ruby

#205

Post by jb3689 »

pdimitar wrote: post #202
jb3689 wrote: post #200

Earlier quoted context omitted.

Was that an argument? It seems pretty clear that that is not the goal of Rails. I'm arguing here that "Rails can't be performant" is not necessarily true

Sadly often this is the argument, yes. I am glad to see that there are much more reasonable Rails devs out there compared to some rather toxic individuals around in HN at least! A lot of tech can be fine-tuned to be very performant. My point was (still is) that there exist technologies today that allow you to delay your scaling decisions much further in future, compared to what a stock Rails app (without any performa…

+1 I definitely agree with this. Today there are many strong languages/frameworks that are just as productive or close to as productive as Rails, particularly with more modern languages. I was really impressed by Phoenix when I worked with that. It was very easy to scale out when the time came because of all the support OTP gave you and because of design decisions like immutability by default

Re: How to Fix Slow Code in Ruby

#206

Post by jb3689 »

pcmoney wrote: post #122
praveenperera wrote: post #97

I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…

If you want the luxury of scale problems down the road you do RoR until you lock down that first couple billion dollars of valuation. Just ask Stripe, Github, AirBnB, Gusto, Shopify, Coinbase, Dropbox, Twitter, Door Dash etc. Then you can have the "problem" of picking the wrong language. Massive survivorship bias in the panning of Ruby/RoR IMO... Also the Ruby/RoR community and culture is better than most other langu…

> Also you need to KNOW the language will be there with a community in 10 years and that it has a history of evolving without screwing over the community.

I don't think this is true at all. Where was Rails 10 years ago? It was pretty bad compared to today's Rails. If the Rails 2 and Rails 3 rewrites never happened then RoR likely would've been superseded by something else and be "dead" today. The point is that Stripe, Github, etc were all early adopters of Ruby and accepted that risk

> You need a talent pool of thousands

I also don't think this is true. You need to hire the right people and you need for them to stick around. And you need to be in the right line of business obviously. Again most of the companies you listed were small/passionate/scrappy for a long time

Re: How to Fix Slow Code in Ruby

#207

Post by thirdusername »

pdimitar wrote: post #196
thirdusername wrote: post #193

Earlier quoted context omitted.

That's not remotely true. If this is happening to you then you're almost certainly having N+1 problems which is architectural and would affect any solution you're using. Add google trace to get a breakdown of your requests SQL that's executing. In an unusual situation it is possible in PG to have a very large pg catalog if you have thousands of tables and schemas which is resolved at run-time because Rails resolves m…

I can only presume things have improved in the meantime. Still, I regularly chat with Rails devs and to have a MacBook Pro 2018 return responses in 150+ ms is alarming. But you might be right that it could be a N+1 query problem. Even without those though, I've still seen Rails apps perform quite horribly. So 50/50 from me, you might be correct but I wouldn't entirely discount the option that Rails is still quite sub…

I mean I see rails perform horribly too, it's my job to go in and fix things, and I focus a lot on fundamentals (what's your DB doing, what data do you need to serve the request, what shouldn't be inside of the request-response cycle).

Because a lot of web developers these days build applications and ORM's are great but make certain patterns convenient so it's really easy to code yourself into places that don't scale. Then people reach for various caching solutions rather than taking a step back and looking at what's actually executing.

I've seen just about every bad pattern you can imagine and it's not usually obvious because the code looks simple enough. Like that permission check in your controller is actually serializing 1000 ids and querying against them, or that .first doesn't have an index so you're sorting the whole table, and much worse than that.

Re: How to Fix Slow Code in Ruby

#208

Post by pdimitar »

thirdusername wrote: post #207
pdimitar wrote: post #196

Earlier quoted context omitted.

I can only presume things have improved in the meantime. Still, I regularly chat with Rails devs and to have a MacBook Pro 2018 return responses in 150+ ms is alarming. But you might be right that it could be a N+1 query problem. Even without those though, I've still seen Rails apps perform quite horribly. So 50/50 from me, you might be correct but I wouldn't entirely discount the option that Rails is still quite sub…

I mean I see rails perform horribly too, it's my job to go in and fix things, and I focus a lot on fundamentals (what's your DB doing, what data do you need to serve the request, what shouldn't be inside of the request-response cycle). Because a lot of web developers these days build applications and ORM's are great but make certain patterns convenient so it's really easy to code yourself into places that don't scale…

Sure. This is a thing regardless of language and framework. Point is, there exist some of them that are quite forgiving and don't give you a 150+ ms response time out of the box like Rails does for a number of projects I inherited in the past.

Re: How to Fix Slow Code in Ruby

#209

Post by b2gills »

jerf wrote: post #57
meesterdude wrote: post #21

Earlier quoted context omitted.

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…

"Sinatra + Sequel is already very competitive in web performance with Go" A lot of the time, that "competitive with X" in web frameworks is because the scripting language has a web server coded in something other than the scripting language. 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. So when you benchmark a "tight loop" in those languages, y…

While Raku is generally slower than other languages, there are times when it is is faster than those same languages.

There was even one report of it being faster than C/C++.

(My guess is that the C/C++ code was doing a lot of string copies and/or scanning for a null terminator. The MoarVM backend doesn't generally do either of those things.)

Re: How to Fix Slow Code in Ruby

#210

Post by rafaelfranca »

jashmatthews wrote: post #172
monadic2 wrote: post #168

Earlier quoted context omitted.

Which tracing jit would you recommend for production work? The implication is, of course, that there isn’t a good one. This isn’t ruby the language’s fault, it’s just weird that after like 15 years being the go-to tool for VCs there’s no substantial investment in the core infrastructure. We just gotta wait for banking software to be written in it, I guess, so there’s a vested interest in it over the long term. Edit:…

JRuby optimizes method_missing in production right now so there's no need to wait for a tracing JIT. I hope that Shopify will start to invest more into R&D for CRuby as well now as well as having Chris there working on TruffleRuby. I'm not sure what you're trying to say with the last part because Ruby works quite differently to Lua or Self here and Self has been "fast" for 30+ years anyway.

> I hope that Shopify will start to invest more into R&D for CRuby as well now as well as having Chris there working on TruffleRuby.

Hi,

I'm the Manager of the Ruby and Rails Foundations team at Shopify.

We are investing a lot on R&D for CRuby as well.

We have 6 people working full time on Ruby implementations, both CRuby and TruffleRuby. Not only Chris Seaton is here, but we have two CRuby Core members as part of the team, Aaron Patterson being one of them.

Post reply on HN