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

181–190 of 213 posts

Re: How to Fix Slow Code in Ruby

#181

Post by jbverschoor »

karmakaze wrote: post #60
remmargorp64 wrote: post #42

Earlier quoted context omitted.

Because crystal lang has all of the main syntax and features that people love about Ruby, but it's way faster because of the typing and compiling. "Fast as C, slick as ruby"

The compiler would have to dramatically increase in speed to make it effective. I tried using Crystal to build a small app using Amber or Lucky frameworks. They weren't fast enough for a flowing edit/compile/run workflow. Ended up using Kemal which is like Sinatra and nowhere like Rails.

Yeah that's the problem I had too. It'd be nice if there's an interpreted and a compiled way of running. Preferrably with hotcode swap

Re: How to Fix Slow Code in Ruby

#182

Post by joelbluminator »

toomanybeersies wrote: post #160
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…

Interesting, how are you guys thinking of solving this issue? I'd go for cache or just migrate the table to a different structure I guess

Re: How to Fix Slow Code in Ruby

#183

Post by joelbluminator »

toomanybeersies wrote: post #174
joelbluminator wrote: post #116

Earlier quoted context omitted.

> there’s plenty of languages out there that developers can be just as productive with There aren't that plenty really. Golang has nothing like Rails, neither does Node. You can say Django / Laravel but then it's the same performance issues. Or maybe you're talking good old enterprise software like Spring / Asp. I don't think Ruby/Rails should feel inferior to any of those names for web development.

I think you can absolutely be just as productive with JS, but it's also easy to be incredibly unproductive. The problem I have with JS (both for server side and client side) is that there's usually several different packages/libraries/frameworks to achieve the same goal, and often one gets deprecated in favour of another, requiring constant updates and changes to the development and build environment. JS development…

> The problem I have with JS (both for server side and client side) is that there's usually several different packages/libraries/frameworks to achieve the same goal, and often one gets deprecated in favour of another, requiring constant updates and changes to the development and build environment. JS development is all about the flavour of the week. For example gulp/grunt/webpack, or NPM/bower/yarn. This is compounded by the lack of a standard library

So which ecosystem is more productive then? What you just described is horrible for a company like Shopify; they aren't a 3 men team working in a garage. And even for a small team, why would you wanna chase a crazy ecosystem like that instead of focusing on your actual product?

Re: How to Fix Slow Code in Ruby

#184

Post by fxtentacle »

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 behind the scenes magic.

Re: How to Fix Slow Code in Ruby

#185

Post by antirez »

pdimitar wrote: post #61
joelbluminator wrote: post #29

Earlier quoted context omitted.

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

Local caches and local node caches are both very useful. (That's why Redis 6 introduces this https://redis.io/topics/client-side-caching), but anyway from what I saw in the past, the major speedup of using Redis in such a context is that you want to use a shared very fast view that is global in nature. A simple to understand, but good example, is the leaderboard problem in multiplayer games that have million of users (Facebook games and such). Even if you have a local cache, and even if you have an additional store where you record the high score of each user, you need a global and very fast to update view of all the sorted scores, to tell the user its rank, users nearby, the rank of their friends. There are a number of problems like that that require to use different data structures and a global view. The problem is that using Redis with the Memcached mindset, will always severely limit the potential benefits.

Re: How to Fix Slow Code in Ruby

#186

Post by pdimitar »

antirez wrote: post #185
pdimitar wrote: post #61

Earlier quoted context omitted.

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

Local caches and local node caches are both very useful. (That's why Redis 6 introduces this https://redis.io/topics/client-side-caching ), but anyway from what I saw in the past, the major speedup of using Redis in such a context is that you want to use a shared very fast view that is global in nature. A simple to understand, but good example, is the leaderboard problem in multiplayer games that have million of user…

Yes. Redis has very valid use cases.

You're quite right: people using it as a mere cache don't get most of its benefits.

Re: How to Fix Slow Code in Ruby

#187

Post by toomanybeersies »

joelbluminator wrote: post #183
toomanybeersies wrote: post #174

Earlier quoted context omitted.

I think you can absolutely be just as productive with JS, but it's also easy to be incredibly unproductive. The problem I have with JS (both for server side and client side) is that there's usually several different packages/libraries/frameworks to achieve the same goal, and often one gets deprecated in favour of another, requiring constant updates and changes to the development and build environment. JS development…

> The problem I have with JS (both for server side and client side) is that there's usually several different packages/libraries/frameworks to achieve the same goal, and often one gets deprecated in favour of another, requiring constant updates and changes to the development and build environment. JS development is all about the flavour of the week. For example gulp/grunt/webpack, or NPM/bower/yarn. This is compounde…

I think that it can be a productive ecosystem if you have experienced technical leadership that's proactive in keeping things up to date. If you spend a bit of time every month or two keeping your dependencies up to date it's not too painless, but if you neglect it for years, then it's an absolute pain to update.

I've discovering this the hard way as I slowly upgrade our front end from AngularJS 1.4, no transpiler, gulp, and bower. Almost much nothing has been upgraded in 5 years, which is like 50 javascript years.

JS is not a great language to use if you're an independent beginner, you either have to follow a tutorial blindly to get a boilerplate setup and hope that in the 6 months since it was written nothing has changed in the libraries used and the tutorial is out of date, or you can spend hours learning how to structure a JS app.

I feel like I'm being harsh on JS. Ruby/Rails is an incredibly productive ecosystem for a beginner, but has the same problems with maintainability and upgrading if you neglect it too.

Any framework isn't productive when you're in greater technical debt than the Weimar Republic, and it's easy to write bad code in any language if you're lacking experience. Upgrading dependencies in any ecosystem is difficult if you don't touch your gemfile or package.json in half a decade. I've had the same problems upgrading our Rails app as our AngularJS app, I'm just much more qualified to handle them.

There were also no experienced Ruby/Rails or JS/AngularJS developers at my work until I joined (and there's still no experienced JS devs), and we've always been pushed to ship features, not improve performance or keep our dependencies up to date, so I've had limited opportunities to work on fixing technical debt. Not entirely sure why you'd create a product with two frameworks none of your employees have any experience in. On the plus side, with all this spare time I've had during lockdown, I've managed to make good headway in resolving a lot of that debt, beats spending my days watching Netflix or playing video games.

Re: How to Fix Slow Code in Ruby

#188

Post by meesterdude »

stevebmark wrote: post #91
meesterdude wrote: post #34

Earlier quoted context omitted.

I've seen conflicting benchmarks on this showing different results - possibly has changed over time, or run different comparisons. What you linked seems current at least.

No, both your post and this reply are dogmatic. As I said, Ruby is the slowest modern dynamic programming language (and it's much slower than Perl). I really wish the Ruby community would listen to valid criticism. All dynamic languages are deeply flawed in some way, especially Ruby, and most ecosystems are open to learning from others.

> All dynamic languages are deeply flawed in some way, especially Ruby

That sounds pretty dogmatic itself. You don't have to like dynamic languages - but that doesn't mean they are deeply flawed. The same could be said for statically typed languages with a different set of values.

Re: How to Fix Slow Code in Ruby

#189

Post by meesterdude »

pdimitar wrote: post #68
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…

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 rails has a slower performance vs. Ruby + Sinatra.

Re: How to Fix Slow Code in Ruby

#190

Post by ykevinator »

rdoherty wrote: post #76

First thing I tell anyone when they say "this code is slow because of X" is to profile it. Profile, profile, profile! More often than not your assumptions are wrong. There's a myriad of tools out there for profiling, some language specific, some not. Learn at least one of them well, how to read flamegraphs and how to benchmark properly (warmup code, synthetic vs real traffic, etc). There's definitely a jump between m…

Second this, more often than not
Post reply on HN