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

121–130 of 203 posts

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

#121

Post by slimdave »

strken wrote: post #30
rahimnathwani wrote: post #15

Earlier quoted context omitted.

"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 w…

No post body was provided.

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

#122

Post by rob74 »

seanhunter wrote: post #82

The biggest database performance problem that I have seen time and time again over the 20+ years I've been using sql databases now is caused by people not understanding that databases are relational (ie designed to perform efficiently over tables, not individual rows) and so running code that essentially causes hundreds/thousands of individual queries where they could just do one big query. Any time you are doing a s…

Sounds obvious... of course, sometimes ORM and other abstraction layers conspire to hide that you are doing queries in a loop.

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

#123

Post by boxed »

rob74 wrote: post #119
codedokode wrote: post #101

Earlier quoted context omitted.

If the query selects a small number of rows and columns, and uses an index, it typically takes less than 1 ms on modern hardware. At least with MySQL. ORM however might be slow. For example, taking 100 rows from SQLite with SQLAlchemy takes 1ms, but getting them as ORM objects takes 8 ms.

And the ORM is written in... Ruby? So then we are back to "Ruby is slow".

SQLAlchemy is python. Which is slower than Ruby :P

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

#124

Post by thom »

gedy wrote: post #25
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..

Hasura is Haskell, not Erlang, I thought.

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

#125

Post by boxed »

seanhunter wrote: post #82

The biggest database performance problem that I have seen time and time again over the 20+ years I've been using sql databases now is caused by people not understanding that databases are relational (ie designed to perform efficiently over tables, not individual rows) and so running code that essentially causes hundreds/thousands of individual queries where they could just do one big query. Any time you are doing a s…

Django has pretty great features for handling exactly this. Unfortunately it doesn't by default warn you if you're missing this optimization. I've had to write that warning system myself into iommi, but with that on it's super nice.

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

#126

Post by eru »

boxed wrote: post #125
seanhunter wrote: post #82

The biggest database performance problem that I have seen time and time again over the 20+ years I've been using sql databases now is caused by people not understanding that databases are relational (ie designed to perform efficiently over tables, not individual rows) and so running code that essentially causes hundreds/thousands of individual queries where they could just do one big query. Any time you are doing a s…

Django has pretty great features for handling exactly this. Unfortunately it doesn't by default warn you if you're missing this optimization. I've had to write that warning system myself into iommi, but with that on it's super nice.

Well, Django has an ORM that makes this kind of feature necessary in the first place? ORM's are trying to hide the relational nature of your db, don't they?

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

#127

Post by Lio »

boredtofears wrote: post #103
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,…

I'm gonna play devil's advocate here: Ruby sucks in large codebases where conventions aren't well defined (unlike Rails, which has well understood concepts and abstractions). Having no ability to do any kind of static analysis means a large legacy codebase will contain giant rabbit holes for you to fall into any and everywhere you look -- unless, of course, the architect(s) responsible for the codebase thought very c…

> Having no ability to do any kind of static analysis

Wouldn't Sorbet count as static analysis? It even supports gradual typing specifically for legacy codebases.

https://sorbet.org/docs/gradual

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

#128

Post by eru »

kaba0 wrote: post #118
Mikeb85 wrote: post #57

Earlier quoted context omitted.

> No, Ruby is slow. Its GC is ungodly slow. Ruby is quicker than Python and that's the most popular programming language there is at the moment. > And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency You definitely can. You've been able to fork processes for longer than I can remember. Ractors just became a thing, making multithreading cheaper and easier. Ruby's also had multit…

> Python and that's the most popular programming language there is at the moment. Ordering the top 3 languages is “subjective”, let’s say that they are Javascript, python and java. And out of these, python is 10x slower than the other two.

Soon to be only 5x slower. There's some serious performance improvements going on in CPython.

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

#129

Post by slimdave »

more_corn wrote: post #19

The default ORM in Ruby… not great at scale. I had a large client with moderate traffic, they were slow because they were absolutely crushing their DB. Now granted it was not JUST ruby, but ruby was a big part of it. We profiled their slow queries and found stuff no human would think is sane. Active record is great for the developer and terrible for database optimization. Which is fine until you try to scale. Then yo…

No post body was provided.

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

#130

Post by codedokode »

dimgl wrote: post #11
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/

> Keep all logic out of the database. It already is the slowest point. And hardest to scale up. That's... weird advice. I think a lot of what happens in Rails projects (based on my very limited experience) is that developers start to rely on this easy syntax that ActiveRecord provides and stop thinking about the queries that the ORM is creating. So you end up with these massive N+1 queries that kill performance. This…

> A majority of what an ORM provides can be solved by a view or a function.

If you want to get a single number or column of numbers - then yes, you can go with an SQL query. But if you need to get data about products in a store, you'll have to fetch the data and create objects for every product. Wow, you have just written an ORM.

Post reply on HN