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

101–110 of 203 posts

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

#101

Post by codedokode »

boloust wrote: post #60

I was left confused after reading this article. 1. It claims Rust is ~10x faster than Ruby, based on a benchmark that reads a 23mb file, and then iterates over the data a single time. In my experience, Rust is between 20-100x faster than Ruby in purely CPU-bound workloads. But the author's main contention is that most work is IO-bound instead of CPU-bound, so probably not a big deal. 2. The author claims "it hardly m…

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.

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

#102

Post by boloust »

wonnage wrote: post #96
boloust wrote: post #60

I was left confused after reading this article. 1. It claims Rust is ~10x faster than Ruby, based on a benchmark that reads a 23mb file, and then iterates over the data a single time. In my experience, Rust is between 20-100x faster than Ruby in purely CPU-bound workloads. But the author's main contention is that most work is IO-bound instead of CPU-bound, so probably not a big deal. 2. The author claims "it hardly m…

That’s covered on literally the line after the chart: > The parsing (juggling of data) takes the majority of time: DateTime::parse

Yes, that's the part I'm confused about. This looks like a case where the vast majority of request time is spent in Ruby, so it would seem a faster language could give a significant speed up.

But right after seeming to acknowledge this, the author instead concludes that "even with a very poor performing ORM, the Database remains the primary time consumer".

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

#103

Post by boredtofears »

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 carefully about this and limited the number of abstractions. If they didn't, you're left stepping through all the metaprogramming and one-off abstraction implementations.

Obviously, my experience is anecdotal, but I've decided my current job is the last Ruby job I'll take. I don't see any reason to pick Ruby over Typescript if you're not using a popular framework. Types save an incredible amount of time when you're ramping up.

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

#105

Post by boredtofears »

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…

That's not a good reason to stay away from ActiveRecord. AR has plenty of ways to write optimal queries (all the way down to raw SQL). That said, green developers often won't ever go that far due to not knowing SQL well enough. No matter what, you gotta have some competency with SQL whether you're using an ORM or not.

Things like DB views come with their own problems and constraints, as well as DB level functions (stored procedures).

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

#106

Post by CoolCold »

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…

> We had to completely abandon Docker for Ruby on Rails because the performance was absolutely abysmal, even with VirtioFS enabled.

can you share more details on this? not sure I get how any kind of VirtioFS comes into the game here

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

#107

Post by ngc248 »

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…

You are exactly right and the pitfalls you talk about are common to all dynamically typed languages.

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

#108

Post by Mikeb85 »

BeefWellington wrote: post #90
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…

Ruby is quicker than Python and that's the most popular programming language there is at the moment. Do you have any reputable sources for this? All I can find are benchmarks run by companies with clear vested interests in showing one language is faster than the other. Also, this isn't quite the strongest argument for its performance; popularity hasn't been tied to performance for a long time (see: all those years No…

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

Of course, in the real world it doesn't really matter. Both are used in places where performance doesn't really matter as long as they're fast enough. But anyone with experience with both knows they're both slow (well, some Python fanboys try to pretend otherwise).

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

#109

Post by ngc248 »

KingOfCoders wrote: post #91

I do think this might have been true in the past, but SSDs have changed the game for databases. Databases became 10x faster over night but this hasn't sunk in to every developer yet. Also ORMs have created an environment, where bad queries are sent to the database for questionable gains (after saving time writing some initial code). After writing a nice Java ORM in the 90s myself (also wrote my own Ruby ORM framework…

True ... I always preferred to roll my own DAL instead of an ORM, because when you actually get into the weeds, the kinda optimizations you can do with your own queries will always be better than what an ORM can do.
Post reply on HN