Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's not Ruby that's slow, it's your database

berk.es

Post reply on HN
Print view View original

21–30 of 203 posts

Re: It's not Ruby that's slow, it's your database

#21

Post by favorited »

joshmn wrote: post #5
likeabbas wrote: post #2

No, Ruby is slow. Its GC is ungodly slow. And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency.

How many developers will really need it though? It's fast enough for Stripe's API, it's fast enough for Shopify; hardware in exchange for productivity is a pretty fair trade.

Except most companies won't attract the same top-tier Ruby/Rails talent. For example, it looks like 1/3 of the current Rails Core Team work at Shopify, including the person who is the #1 all-time Rails contributor.

Re: It's not Ruby that's slow, it's your database

#22

Post by imchillyb »

pixl97 wrote: post #12
mrinterweb wrote: post #9

In my experience 9/10 web application performance problems are related to database interactions. Is the query using an index? Are you hammering your DB with 300 N+1 queries to render an API response. These are usually the biggest offenders when poor performance is observed. If you're interactions with you DB are bad, it doesn't matter what programming language you use, performance will be mostly equally awful regardl…

Bad indexing, no indexing, and fragmented indexes seem to cause no end of issues, and there always seem to be shortages of people capable of fixing it properly.

In order to fix a problem, one must be able to first identify the problem. Many people are still unaware of how indexing works, even though the devices they utilize daily perform this action routinely.

Re: It's not Ruby that's slow, it's your database

#23

Post by WkndTriathlete »

lmm wrote: post #10
rahimnathwani wrote: post #4

"Keep all logic out of the database. It already is the slowest point. And hardest to scale up." I don't think this is true in all cases. Sure, ORMs are awesome, but sometimes you need to write SQL queries by hand, and those queries necessarily implement some business logic (even if they're just retrieving data). Nice explanation here: https://tapoueh.org/blog/2017/06/sql-and-business-logic/

There is always an alternative to writing SQL queries by hand, and it's usually a better one IME. Any ORM worth its salt will let you do the query in your blog post via the ORM, as a single query.

> There is always an alternative to writing SQL queries by hand, and it's usually a better one IME.

I spent years writing code using Spring/Hibernate, and I can state with certainty that both of those statements are demonstrably false.

Every application starts with good intentions, a simple CRUD webapp, and an ORM, then at some point the business requirements yield an N+1 problem in ORMs or several non-trivial left joins into records that don't map the shape of the entities. At that point it's far easier to write the query in straight SQL and produce a straightforward mapping into the record structure, which doesn't play well with the ORM because that bypasses its entity cache, which causes another huge set of problems on its own. So now not only is there ORM maintenance and SQL maintenance, there is now a problem with the conjunction of the two technologies.

Re: It's not Ruby that's slow, it's your database

#24

Post by caladin »

WkndTriathlete wrote: post #23
lmm wrote: post #10

Earlier quoted context omitted.

There is always an alternative to writing SQL queries by hand, and it's usually a better one IME. Any ORM worth its salt will let you do the query in your blog post via the ORM, as a single query.

> There is always an alternative to writing SQL queries by hand, and it's usually a better one IME. I spent years writing code using Spring/Hibernate, and I can state with certainty that both of those statements are demonstrably false. Every application starts with good intentions, a simple CRUD webapp, and an ORM, then at some point the business requirements yield an N+1 problem in ORMs or several non-trivial left j…

I agree but I think Hibernate is an extreme. There is a middleground, query builders, which enable dynamic query construction (e.g. dynamically appending filter predicates) with reduced cognitive load of something like Hibernate.

I personally was heavily in the camp of "write raw queries ideally with code generation for statically typed/generated code" (as exist in Rust, Go, TypeScript, etc.), but I have since tempered my position since it does become a bit brittle and repetitive. Lately I've been playing with Jooq and it seems great.

There are tradeoffs everywhere though, so with Jooq you still aren't 1-to-1 with raw SQL, there is a bit to learn, but I consider it a worthwhile investment (and a minor one relative to an actual ORM).

Re: It's not Ruby that's slow, it's your database

#25

Post by gedy »

likeabbas wrote: post #2

No, Ruby is slow. Its GC is ungodly slow. And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency.

Yeah antidotal, but I was doing some tests of an existing Rails app API compared to Hasura (erlang GraphQL server) talking to same DB, and querying same data was like 100x faster in Hasura..

Re: It's not Ruby that's slow, it's your database

#26

Post by spoiler »

drewbug01 wrote: post #13

I think my favorite part is buried in footnote 5: > Ironically, the performance issue becomes less articulated in this non-http, non-rails context, yet in these cases people generally dismiss ruby as option, for its performance-issues. Which, catch-22, is one of the reasons Ruby is hardly used outside of Rails (and/or Web). It's a shame that most people only write Ruby in the context of Rails. It's a lovely language,…

> It's a shame that most people only write Ruby in the context of Rails

I fully agree with this! I used to use Rails for a few years (not professionally, FWIW), but didn't enjoy Rails that much. Even though, it's hands down the best "in class" framework, it beats anything in the JS or Python ecosystems (and claiming Django is anything close to Rails is just offensive to Rails).

But anyway, I've yet to find something that's as good as Ruby for daily scripts or task automation. Ruby is one of those few languages you can just read (I can't explain it well), and coming back to old Ruby code, the "wtf is going on here" moments are fairly scarce (sans code that touches metaprogramming/eigenclasses/DSLs, but even then it's more straightforward than in other languages). Lately I tend to just use Fish for most things (which are simple), but still reach for Ruby when the task is a bit more involved. Like, yeah there's Python, but I never liked Python. That's not to say Ruby isn't without any warts, but that's just... Technology, I guess lol.

Re: It's not Ruby that's slow, it's your database

#29

Post by falcolas »

mrinterweb wrote: post #9

In my experience 9/10 web application performance problems are related to database interactions. Is the query using an index? Are you hammering your DB with 300 N+1 queries to render an API response. These are usually the biggest offenders when poor performance is observed. If you're interactions with you DB are bad, it doesn't matter what programming language you use, performance will be mostly equally awful regardl…

As an ex-DBA, the lack of understanding - and even basic performance monitoring - of your average Sr Software dev is mind blowing.

As a side note, the willingness of those same devs to allow queries of arbitrary size and constraints hit their db is equally frustrating.

“As long as we prevent against SQL injection, who cares?”

Re: It's not Ruby that's slow, it's your database

#30

Post by strken »

rahimnathwani wrote: post #15
lmm wrote: post #10

Earlier quoted context omitted.

There is always an alternative to writing SQL queries by hand, and it's usually a better one IME. Any ORM worth its salt will let you do the query in your blog post via the ORM, as a single query.

"Say now we want to display the album list sorted by album’s duration, shortest first." How would we do this in an ORM like ActiveRecord or Django ORM, without generating multiple queries?

I haven't used Rails or ActiveRecord for a long time, but from memory it gives you an escape hatch in the form of Arel that lets you represent parts of your query as SQL while still using the ORM for the rest.

Edit: I think it's something like

    Album
      .select(:id, :name, "SUM(songs.length) AS total_length")
      .left_outer_joins(:songs)
      .group(:id)
      .order("SUM(songs.length) ASC")
I think you don't even need to explicitly wrap it in Arel.
Post reply on HN