[HN Gopher] It's not Ruby that's slow, it's your database
___________________________________________________________________
It's not Ruby that's slow, it's your database
Author : ksec
Score : 5 points
Date : 2022-11-08 20:43 UTC (2 hours ago)
(HTM) web link (berk.es)
(TXT) w3m dump (berk.es)
| likeabbas wrote:
| No, Ruby is slow. Its GC is ungodly slow. And you can't truly
| multithread, thus you can't properly parallelize or maximize
| concurrency.
| Tainnor wrote:
| I don't understand why the author first describes how bad N+1
| queries are and then later claims that they are sometimes good?
| Yes, of course that can be true in very specific circumstances,
| but in many cases I've seen atrocious performance due to N+1
| queries and fixing them was the first step in making an
| unresponsive website perform.
|
| Don't also really agree that adding validations, joins etc. to
| your DB is "coupling your application logic to the DB" or that it
| makes the app slower (???). The thing that is coupling your
| business logic to the DB is a bad architecture which,
| unfortunately, most ORMs (including ActiveRecord) encourage. The
| fact that you can access a propery on an ActiveRecord object in a
| view and have this secretly make a database call, is one of the
| reasons for those infamous N+1s.
| rahimnathwani wrote:
| "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/
___________________________________________________________________
(page generated 2022-11-08 23:01 UTC)