How to Fix Slow Code in Ruby • Hacker News Board

Re: How to Fix Slow Code in Ruby

#191

Post by lizmat » Fri, May 15, 2020, 11:49 AM UTC

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…

Please note that Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media). Also: not sure how long ago you tried using Perl 6 and found it slow. If your data is from the Parrot days, it is definitely out of date: the MoarVM backend is at least two orders of magnitude faster.

Re: How to Fix Slow Code in Ruby

#192

Post by ksec » Fri, May 15, 2020, 11:51 AM UTC

pvsukale3 wrote: post #35

chrisseaton wrote: post #31

Earlier quoted context omitted.

Yes TruffleRuby struggles to run test code because it works against the optimisations we add to make production code fast. For example when you add more profiling to better optimise the hot code it makes the cold code slower, and tests are almost all cold code. Also our C extension emulation layer used to be extraordinarily slow while we made it work correctly, and it's still rather slow. It's a challenge but we're w…

Unrelated: But thank you for the work you and your team are doing. I wish you all the success.

Agreed. I often felt people give little credit and appreciation to the Truffle Ruby teams.

Re: How to Fix Slow Code in Ruby

#193

Post by thirdusername » Fri, May 15, 2020, 1:04 PM UTC

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.

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 models and types through db introspection, and the types specicially are only loaded during runtime. But that would be very unusual. I'm working on solving this in Rails because this unusual sittuation is affecting us.

Re: How to Fix Slow Code in Ruby

#194

Post by tim333 » Fri, May 15, 2020, 1:54 PM UTC

pdimitar wrote: post #59

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.

> Phew, I'm glad GitHub and Shopify's scale is still small. Phew, good thing they can afford to burn a lot of cash for hosting.

I guess that's so though it's interesting in the early days Github didn't:

>...a web startup like ours doesn’t need any outside money to succeed. I know this because we haven’t taken a single dime from investors. We bootstrapped the company on a few thousand dollars and became profitable the day we opened to the public and started charging for subscriptions.

Tom Preston-Werner in 2008. I guess the thing is not how much the hosting costs in absolute terms but how much it costs relative to what customers are prepared to pay for the service.

Re: How to Fix Slow Code in Ruby

#195

Post by jb3689 » Fri, May 15, 2020, 2:29 PM UTC

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.

ActiveRecord is configurable. You have options to bypass the serializer. Rails can't magically have the correct answer to every problem out of the box without tweaking

"The default behavior is slow!"

"Don't use the default behavior?"

Re: How to Fix Slow Code in Ruby

#196

Post by pdimitar » Fri, May 15, 2020, 2:44 PM UTC

thirdusername wrote: post #193

pdimitar wrote: post #154

Earlier quoted context omitted.

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.

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 suboptimal in terms of performance, compared to many other frameworks.

Re: How to Fix Slow Code in Ruby

#197

Post by pdimitar » Fri, May 15, 2020, 2:47 PM UTC

tim333 wrote: post #194

pdimitar wrote: post #59

Earlier quoted context omitted.

> Phew, I'm glad GitHub and Shopify's scale is still small. Phew, good thing they can afford to burn a lot of cash for hosting.

I guess that's so though it's interesting in the early days Github didn't: >...a web startup like ours doesn’t need any outside money to succeed. I know this because we haven’t taken a single dime from investors. We bootstrapped the company on a few thousand dollars and became profitable the day we opened to the public and started charging for subscriptions. Tom Preston-Werner in 2008. I guess the thing is not how mu…

Once a business grows to certain size and beyond the shareholders don't want to hear anything about tech rewrites. They are happy the product is working, they are not alarmed by slow response times (which GitHub has plenty of on my gigabit connection that streams 4k@30fps without any lag) unless there's a big customer churn, and hosting costs, even if big-ish, to them are just the cost of doing business.

My point is, yes, you are right -- but there's a lot of conservatism involved once the business gets to a certain size. Nobody cares about improving anything from then on (which usually leads to the now-giant to start steadily losing relevance; GitHub is quite far from that but we all remember Microsoft, right?).

Re: How to Fix Slow Code in Ruby

#198

Post by pdimitar » Fri, May 15, 2020, 2:48 PM UTC

jb3689 wrote: post #195

pdimitar wrote: post #154

Earlier quoted context omitted.

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.

ActiveRecord is configurable. You have options to bypass the serializer. Rails can't magically have the correct answer to every problem out of the box without tweaking "The default behavior is slow!" "Don't use the default behavior?"

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?

Re: How to Fix Slow Code in Ruby

#199

Post by jb3689 » Fri, May 15, 2020, 2:59 PM UTC

fxtentacle wrote: post #184

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 languages bring their own ecosystem and associated phosphophy of how you'll use it. The Ruby phosphophy seems to be lots of magic (in a good way) and in exchange you accept that details get lost behind the scenes and that it's only fast enough, but not truly fast. Switching to a language that values speed with tools that have a different phosphophy can then make such a bug much more visible, due to the lack of b…

While the phrasing irks me, I think I agree with the sentiment: "languages that value speed tend to expose more of the details, thus when presented with a performance problem, you have more options ready at your disposable". One of the biggest barriers for me personally as a long time user of high-level languages is going down into C internals and feeling like I can safely make changes. It also sucks if you don't want something that comes out of the box with Ruby (say you want a more memory efficient array than what Ruby gives you). C extensions allow you to add these things, but the knowledge is specialized and writing C extensions can feel like a black art due to a relative lack of resources on them

There are two other alternative interpretations that I think are untrue however:

* "languages that value speed give you tools that expose more of the details and thus help you avoid adding defects in the first place" which I disagree with because (1) the average programmer will not understand what most low-level options actually do and (2) exposing more options is like trying to program with ones and zeros - at some point low-level abstractions don't scale well in a constantly evolving project

* "languages that value speed generally have fewer abstractions and thus make it easier to find bugs because there is less abstraction" which I think is untrue in projects of meaningful size. Macros are very common to find in languages like C and arguably as complex as metaprogramming in Ruby. Additionally Java is considered a relatively fast language and Java projects often have lots of abstraction

Re: How to Fix Slow Code in Ruby

#200

Post by jb3689 » Fri, May 15, 2020, 3:08 PM UTC

pdimitar wrote: post #198

jb3689 wrote: post #195

Earlier quoted context omitted.

ActiveRecord is configurable. You have options to bypass the serializer. Rails can't magically have the correct answer to every problem out of the box without tweaking "The default behavior is slow!" "Don't use the default behavior?"

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