Yes, index the database. Another thing that can make Rails apps quite fast is using caching (Rails has some builtins that make that easy). In some cases you end up skipping a database lookup and running little Ruby code, which is a huge speedup when you can do it.
It's not Ruby that's slow, it's your database
51–60 of 203 posts
Re: It's not Ruby that's slow, it's your database
#52Yes, index the database. Another thing that can make Rails apps quite fast is using caching (Rails has some builtins that make that easy). In some cases you end up skipping a database lookup and running little Ruby code, which is a huge speedup when you can do it.
Caching seems to be a general purpose approach that got lost the longer my career went on. I suspect as networks and computers got faster people stopped thinking the added complexity was worth it, but it's still invaluable in bigger applications.
Re: It's not Ruby that's slow, it's your database
#53Earlier 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?
[deleted]
Re: It's not Ruby that's slow, it's your database
#54No, 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.
> It's fast enough for Stripe's API...
Stripe is moving to Java.
Re: It's not Ruby that's slow, it's your database
#55Earlier 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…
I use rails every day. Looks close enough. You’d just need to specify the fields with the table name, I.e. ‘albums.id’.
Also, for anyone reading, a total_length method dynamically will be added objects returned. :)
Re: It's not Ruby that's slow, it's your database
#56Earlier quoted context omitted.
A pure query builder is just writing SQL on syntax tree level, more or less. This makes sense for the same reason why you want your macros to operate on ASTs and not raw text. But I would argue that it's still much closer to plain text SQL in the code than to any ORM.
Right, but it lives with your application code and has the same syntax as the application code. That's probably preferable to SQL stored procedures (which often live outside source control).
I’ve found that all this does is make the query less readable. SQL is purpose made for writing queries, and avoids unnecessary syntax noise you get when trying to fit the query into a host language based dsl.
Re: It's not Ruby that's slow, it's your database
#57No, Ruby is slow. Its GC is ungodly slow. And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency.
> 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 multithreaded servers for at least a decade. Not that it even matters that much, most people are using on-demand cloud servers that just spin up more servers when needed, making multi-threading less useful anyway.
Even if you forget Ractors exist, it's like saying C can't do multithreading because it's not in the language definition...
Re: It's not Ruby that's slow, it's your database
#58Earlier quoted context omitted.
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.
> It's fast enough for Stripe's API... Stripe is moving to Java.
Every large enough organisation eventually moves to Java (or C++, or Rust). When you have more bodies than things to do you just optimize... But how did all these startups get so big?
Re: It's not Ruby that's slow, it's your database
#59I 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,…
rails, postgres, PORO, and htmx is a monstrously productive stack
If you are one Rails, why not the hotwire stuff?
Re: It's not Ruby that's slow, it's your database
#60I 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 matters that Ruby halts all code for 15ms to do garbage collection, if the fastest database-query takes 150ms". I've written applications that query Postgres databases with tens of millions of rows, where the 99th percentile response times are 3. This flame graph from the article[0] seem to show that the vast majority of the request time is spent in Ruby parsing timestamps, rather than in the database. This seems to make the opposite point that the author is trying to make. I'm not familiar with this stack, so maybe I'm missing something- can anyone explain?
[0]: https://berk.es/images/inline/flamegraph_sequel_read.svg
