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

151–160 of 213 posts

Re: How to Fix Slow Code in Ruby

#151

Post by cutler »

barrkel wrote: post #55
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…

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.

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.

Re: How to Fix Slow Code in Ruby

#152

Post by joelbluminator »

pdimitar wrote: post #103
mindfulmore wrote: post #89

Earlier quoted context omitted.

> For 3.5 years with Elixir this is the first time I hear that this is a problem. Any data to back this up? My point is that it doesn't come with Phoenix out of the box (unless something has changed?), and that difference in philosophy is the core of what I'm getting at. With rails new I'm getting an end-to-end test suite and chrome driver installation for free. Phoenix also has no plans of implementing something sim…

> My point is that it doesn't come with Phoenix out of the box (unless something has changed?) You put a lot of weight on built-in features of frameworks in your reply. This is not an objective truth and even DHH himself admitted as much -- including in his article "Rails is Omakase" which I very much enjoyed (because he says that the Rails team picks what they deem the best ingredients and if you disagree then you a…

> the people who work with mainstream tech always assume that the smaller community wants more adoption

We all wanna get paid in the end of the day. Lots of Rails devs got spooked that 5 years from now their knowledge will go to shit. A lot of them still feel insecure about the state of Ruby, even with 90B companies like Shopify using it, because they read a blog about how a startup no one heard of migrated from Rails to Elixir. You don't seem to care about any of that and that's great. But let's face it, a lot of the back and forth "what's better tech" wars and shitting on each other's stacks is simply trying (maybe subconsciously) to gain more adoption and to validate our choices in life, and feel good about what we do by feeling superior to others. Just like a religion really or any other form of community. These aren't really academic discussion on what's "better" in my view.

Re: How to Fix Slow Code in Ruby

#153

Post by pdimitar »

joelbluminator wrote: post #152
pdimitar wrote: post #103

Earlier quoted context omitted.

> My point is that it doesn't come with Phoenix out of the box (unless something has changed?) You put a lot of weight on built-in features of frameworks in your reply. This is not an objective truth and even DHH himself admitted as much -- including in his article "Rails is Omakase" which I very much enjoyed (because he says that the Rails team picks what they deem the best ingredients and if you disagree then you a…

> the people who work with mainstream tech always assume that the smaller community wants more adoption We all wanna get paid in the end of the day. Lots of Rails devs got spooked that 5 years from now their knowledge will go to shit. A lot of them still feel insecure about the state of Ruby, even with 90B companies like Shopify using it, because they read a blog about how a startup no one heard of migrated from Rail…

But I am not here to argue what most do. The discussion here, at least from my part, was to encourage someone to give an alternative tech a try. I did, I kept paying my bills with Rails but got intrigued, became better and better with Elixir, rewrote some stuff in it, demonstrated actual hosting savings (and reports being generated in 7 minutes as opposed to 3 hours with the Rails code) and the rest is history.

Even though you and me keep exchanging jabs here I'd like this to stop.

I don't intend to "shit" on anyone's tech choice. What I did and still do intend is to help somebody, here and there, to love their job. I've met a lot of miserable Java and Ruby on Rails devs.

For the sake of the civil discussion we both should stop assuming stuff.

I am grown up enough to not care about validation (and I think everybody shouldn't care about it either but it's not the world we live in, sadly). It's mostly about finding something that clicks better with your brain and gives you a peace of mind while working.

Rails didn't give me that. It gave me anxiety. I had to always be on watch what is shifting beneath my feet. A [mostly] FP tech stack gives you back the control to shoot your own foot as opposed to a library that's a dependency of the dependency of the library you need doing it. Okay? :)

> We all wanna get paid in the end of the day.

Well, exactly. But I also want to be happy while receiving a paycheck.

Re: How to Fix Slow Code in Ruby

#154

Post by pdimitar »

benkuhn wrote: post #141

Really surprised how many commenters are talking about using a faster language when the example of slow code in the post is failing to cache the results of an expensive database query. In my experience, even in "slow" languages, that type of thing is the predominant source of major performance problems, and the supposedly "slow" language would be perfectly adequate if you an stop shooting yourself in the foot (and if…

It is surprising until you realize that Rails' ActiveRecord consistently wastes 100-200ms on every request just to serialize / deserialize data from/to the database.

So yes, a language that's both faster and has less overhead in its ORM / DataMapper library definitely will help you.

Re: How to Fix Slow Code in Ruby

#155

Post by cutler »

pdimitar wrote: post #149
cutler wrote: post #143

Earlier quoted context omitted.

Another point worth mentioning is that Elixir is only optimised for lightweight processes. If you have to do any heavy lifting you're better off with Go or a JVM language, not Elixir. Forget math with Elixir too - it doesn't even have an arrary/vector data structure of its own. Instead it relies on Erlang's hacky implementation.

Which is exactly what many Elixir advocates say. Contrary to what you and others try and insinuate, we are very aware that the language is not a universal tech. So yet again, you guys are smacking at a strawman that's very easy to beat. It's quite tiring to argue with stuff that I never said (and most of Elixir's community haven't said it either). But I think I'll give up for now. :)

That's not been my experience. Whenever I have mentioned the lack of arrays/vectors in the past I have been inundated with Elixir devotees asking me why I need them when Elixir has maps with numeric keys at which point I just throw up my hands in despair.

Re: How to Fix Slow Code in Ruby

#156

Post by pdimitar »

cutler wrote: post #155
pdimitar wrote: post #149

Earlier quoted context omitted.

Which is exactly what many Elixir advocates say. Contrary to what you and others try and insinuate, we are very aware that the language is not a universal tech. So yet again, you guys are smacking at a strawman that's very easy to beat. It's quite tiring to argue with stuff that I never said (and most of Elixir's community haven't said it either). But I think I'll give up for now. :)

That's not been my experience. Whenever I have mentioned the lack of arrays/vectors in the past I have been inundated with Elixir devotees asking me why I need them when Elixir has maps with numeric keys at which point I just throw up my hands in despair.

Not denying it. Every community has bad apples.

It's not charitable to make assumptions for the entire community -- or the tech stack itself -- based on them however.

Seems like you've been chatting with the wrong people. A lot of the ElixirForum regulars -- me included -- are very practical and realistic folk who use several languages all the time.

Re: How to Fix Slow Code in Ruby

#157

Post by cutler »

pdimitar wrote: post #150
cutler wrote: post #139

Earlier quoted context omitted.

Can you elaborate how Rails maitenance is "much higher" than with Laravel given that Laravel is PHP's version of Rails?

This is what I have been told by a former Rails dev who is now doing Laravel. He said that Rails has much more automatically injected code that behaves in a way you can't anticipate intuitively (and many libraries encourage and extend that behaviour). As a former Rails dev myself I agree with that part.

But isn't this exactly what Symfony users accuse Laravel of - too much magic? Laravel's facades are as magical as anything in Rails and Laravel does a lot of code injection. It takes more than one man's opinion to establish a truth.

Re: How to Fix Slow Code in Ruby

#158

Post by pdimitar »

cutler wrote: post #157
pdimitar wrote: post #150

Earlier quoted context omitted.

This is what I have been told by a former Rails dev who is now doing Laravel. He said that Rails has much more automatically injected code that behaves in a way you can't anticipate intuitively (and many libraries encourage and extend that behaviour). As a former Rails dev myself I agree with that part.

But isn't this exactly what Symfony users accuse Laravel of - too much magic? Laravel's facades are as magical as anything in Rails and Laravel does a lot of code injection. It takes more than one man's opinion to establish a truth.

In that case I have been misled by that acquaintance of mine and I apologise for unintentionally spreading misinformation.

(In that case, let's replace Laravel with Phoenix.)

Re: How to Fix Slow Code in Ruby

#159

Post by jordanthoms »

pdimitar wrote: post #154
benkuhn wrote: post #141

Really surprised how many commenters are talking about using a faster language when the example of slow code in the post is failing to cache the results of an expensive database query. In my experience, even in "slow" languages, that type of thing is the predominant source of major performance problems, and the supposedly "slow" language would be perfectly adequate if you an stop shooting yourself in the foot (and if…

It is surprising until you realize that Rails' ActiveRecord consistently wastes 100-200ms on every request just to serialize / deserialize data from/to the database. So yes, a language that's both faster and has less overhead in its ORM / DataMapper library definitely will help you.

Our data-heavy API returns JSON responses from our DB in ~40ms using ActiveRecord. So no, it doesn't waste 100ms on every request! We're serving around 6000 requests like that per second.

Re: How to Fix Slow Code in Ruby

#160

Post by toomanybeersies »

benkuhn wrote: post #141

Really surprised how many commenters are talking about using a faster language when the example of slow code in the post is failing to cache the results of an expensive database query. In my experience, even in "slow" languages, that type of thing is the predominant source of major performance problems, and the supposedly "slow" language would be perfectly adequate if you an stop shooting yourself in the foot (and if…

Most CPU intensive functionality in the core Ruby lib is implemented in C anyway, to ensure performance.

The vast majority of overhead in the rails app I work on is poorly build data models and poorly written queries. It makes no sense to talk about marginal gains of a few percent or a few ms per request when there are DB queries that take multiple seconds to complete.

In our case, a large part of that is due to the decision that someone made 5 or 6 years ago to store large amounts of data as serialized ruby hashes in the DB, rather than JSON (unsure if postgres supported it at the time), or simply as separate tables.

None of the poor performance of our codebase is down to Ruby itself. Most of it is due to features and data models being implemented with no thought for performance, a lot of which wasn't an issue when first written but as we've grown have become a constant thorn in our side (e.g. retrieving a multiple-MB serialized hash from the DB just to grab 3 values, then doing this 10 times in a request)

Post reply on HN