How to Fix Slow Code in Ruby (opens in new tab)

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

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.

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.

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

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

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 working on it.

But TruffleRuby is the only alternative Ruby implementation to even run major applications that I've tried at Shopify.

Are you serious - the whole Shopify test suite finishes under 8 minutes? That's pretty great no? Are there multiple processes running it?

I don't think Dropbox use/d Rails. But you can add Gitlab to that list which is a VERY good company.

> 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

Edit: downvote away for disagreeing. I don’t see anyone presenting a counter argument.

This has not been my experience.

It has been “do it THIS way in ruby” even though either way is perfectly valid (eg list of Literal strings / symbols vs %i or %w.

Lots of bike shedding type discussions on which way is better and unsurprisingly no consistency across the codebase.

There’s also a lot of hidden things you can only learn from years of usage and no clear documentation of when / where features came and went.

All in all every Ruby dev I’ve worked with across 4 companies have all had the same sort of elitist / pretentious attitude compared to Python, Go or Java devs. Ruby has only been second to Scala and Rust devs (so far).

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

Every company has its own particular build system (and configuration of that system), libraries they use, style guide, and file/folder layout. It's also very easy to abuse scoping and class mutability, with only style guides and eslint to save you. It can be a lot of work keeping a larger and older project up to date.

How about Elixir/Phoenix?

I agree for Shopify a rewrite would not make sense.

But I think writing new features, or rewriting some critical paths of the codebase in a new language could make sense.

It's atleast a valid question.

They are clearly already spending a lot of resources optimizing Ruby code to match their demands.

My question is at what point does continuing with Ruby become trying to force a round peg into a square hole?

> I don't see why that would be the case

Well, the extensive use of “method_missing” appears to be staggeringly difficult to optimize short of a tracing jit and it’s also the core idiom of many popular frameworks. Of course it can be faster—if you remove the slow, unique features you can optimize it like any other language.

Yes, and at the time Shopify was started Ruby was likely a very good choice. The parent comment is saying that today there are alternatives that run faster and provide similar levels of productivity.

> Shopify is an insanely huge e-commerce platform (and a $100B company).

That's an interesting note. They have a $90b market cap, trading at ~53 times sales. It's one of the more extreme valuations I've seen in the last 25 years, including the dotcom bubble (and that's saying something with how overvalued everything cloud-related is today).

As one comparison for the absurdity, Yahoo during most of the height of the dotcom bubble, was trading for 30-50 times sales, growing sales faster than Shopify, and they were solidly profitable (Shopify has never earned a consequential profit in its history). That's how bad Shopify's present valuation is, to get good comps you have to reach into the dotcom bubble.

The market thinks they're Amazon-like. The problem is they've never demonstrated any great margins in their platform (despite 14 years and counting) and Amazon's big lift-off in their stock occurred solely due to the ability of AWS to generate immense operating income. Without AWS, Amazon eventually gets the sad multiples of a Target or Walmart on their retail business.

This is an obviously mistaken valuation riding one of the most overvalued markets in US history, one that will most likely brutalize investors that get in late. It's a classic example of how very inefficient and irrational the stock market can be in the shorter term. And no, that doesn't mean an investor should be the fool to step in front of the irrationality train and short it either (everyone here probably has heard the Keynes line about the market remaining irrational longer than you can remain solvent).

It'll take at least 10-15 years at a minimum for Shopify to grow into its present valuation, in the best case scenario, if everything goes perfectly and they some day find some margin in their business. If they eventually manage an enormous $2 billion profit ($1.7b in sales today ttm), they'll still have a 45 PE ratio at today's valuation. That's a prime market example of insanity.

eBay has a vastly superior business (in all regards, including its quasi-monopoly positioning and the tremendous profitability of ebay's platform), trading for a huge discount to Shopify, on the basis of the market's mistaken extrapolation about Shopify's future. If they're lucky, they'll one day be the size of eBay with a fraction of the profit margin (and of course eBay has a mere $29b market cap, 12x op income multiple; compression is a killer). I mention eBay (beyond obvious reasons), because Shopify is likely doing nothing more than pulling future returns forward to an extreme, as eBay once did (leading to a decade of stagnation in the stock).

You’d have to compare them to an equivalent shop in the same market of about the same size with a different stack to get a meaningful answer out of this—I’d say off-hand that it’s very unlikely their edge is tech.

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

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 systems and I can pretty much guarantee that the services running those caches and persistence will not be written in ruby.

You can make anything* scale, but how many CPU cycles you need to burn to get the functionality you want is a matter for the finance department.

If you're running in a lossy business, you can bet that those CPU cycles will begin to cost more than developer velocity is worth, because servers are an eternal and ongoing cost.

On the flip side if you make more money than the infra+devs cost, then nobody is going to hound you for wasting 2x 3x the cost. Because "it's the cost of doing business" is easier to justify when you're cash positive.

> 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 recall Shopify hired a dev who works on a project, FaastRuby, written in Crystal language for their web app.

I guarantee the tradeoffs matter to them

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.

"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, you are running 99% C and 1% your scripting language.

Now, that is not a bad thing. It is a valid result, in the sense that it is a good thing for environments to have fast web servers, and nobody cares what the implementation language is... with perhaps the sole exception of this case, where we're trying to compare the performance of scripting languages by their web server implementation. You can't claim "Scripting Language X is fast because it has a fast webserver!" when the webserver isn't written in Scripting Language X.

(A moment's perusal didn't show me what this particular web server is implemented in. If someone can link me to that web server and show it's implemented in Ruby, I'll be happy to eat my words here. But if the performance is comparable to Go, that's enough evidence it isn't written in Ruby to satisfy me until more evidence comes in. If Ruby isn't a slow language, you've defined "slow language" to the point that no language is slow. There isn't much competition in the "slower than Ruby" field; Perl 6 is pretty much the only entrant I know of. There's a number of languages as slow as Ruby, it is not uniquely slow, but there's almost nothing slower.)

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.

Ruby is slower than php.

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

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

It's interesting because Lars Bak was optimizing Smalltalk and Self VMs in the 90s.

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.

Idiotic. That’s what using the right tool for the job is all about. Ruby isn’t for everything and never will be. Just stick to CRuby (or JRuby if integrating with the JVM). They’re already stable. No point diluting the space with more rubies for superficial reasons like lessening the performance trade off in Ruby when there are many many other languages better suited for high performance algorithms to apply where needed. That’s what good engineering is all about after all. Knowing trade-offs and choosing the right tool for the job, not denying them or trying to fight them like TruffleRuby idiotically does. Shopify is like Canada’s Groupon. The only reason they are profiting is because they have a simple business idea despite their mediocre engineering skills.

Not running most Rails applications is true, but the applications that can be run on TruffleRuby are not quite plain. It can run a web application that serves storefront traffic (source at the end of https://engineering.shopify.com/blogs/engineering/optimizing...)

Nice, JIT in 2.6 makes a significant performance jump https://rubybench.org/ruby/ruby/releases?result_type=Optcarr...

Wow, there are a lot of them!

Yes, Ruby is meant to be easy and magical, but it was never meant to be fast. It's fast enough for most things, but you also wouldn't show up to a drag race with a tuned bicycle.

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?

Here's the official reminder not to use the BEAM for all things - http://erlang.org/faq/introduction.html#idp32557584

I thought the same as you but then I realized that the investment in a tech stack is basically done only once and almost never revisited.

Then people go on all sorts of crazy journeys to justify their investments in pain and burned money.

Even though I get downvoted at places in this thread (and upvoted generously on others), I will never tell to people "you should always just rewrite to Elixir". Meh. If your app works fine, have it be in COBOL or PL/1 if that helps you do your job better.

But as you said, when your app/hosting starts struggling you should start rethinking your choices if all the lower-hanging fruit has been already collected.