It's not Ruby that's slow, it's your database
1–10 of 203 posts
Re: It's not Ruby that's slow, it's your database
#2No, Ruby is slow. Its GC is ungodly slow. And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency.
Re: It's not Ruby that's slow, it's your database
#3I 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.
Re: It's not Ruby that's slow, it's your database
#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:
Re: It's not Ruby that's slow, it's your database
#5No, 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.
Re: It's not Ruby that's slow, it's your database
#6"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/
Yeah, this is bad advice.
For example, Postgres has fantastic "upsert" and data integrity checks that reduce round trips to the database, meaning they're incredibly fast and result in less-complex client code.
Re: It's not Ruby that's slow, it's your database
#7No, Ruby is slow. Its GC is ungodly slow. And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency.
Ruby web guy for 15 years.
95% of the time the problem is poor database choices. Usually to much contention / locks.
On the rare projects where I need something like rabbitmq performance. I don’t use ruby.
Re: It's not Ruby that's slow, it's your database
#8From my experience with Python and Ruby, it's not the database itself, it's the database driver that spends quite some time on serialization and deserialization every time you want to send around some data, even more so when you pack some objects to store as semistructured/json/xml.
So no, it's not the database, it's your interpreted language.
Re: It's not Ruby that's slow, it's your database
#9In 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 regardless of language.
Re: It's not Ruby that's slow, it's your database
#10"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.