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

Yes I was using SQLx when writing Rust code and I've enjoyed it a lot.

Unless they go with a JIT compiler, no real closing of performance gap will happen.

Author here. Sorry for the confusion.

1. I didn't want to make the point that Rust is faster, per sé. But wanted to show why it is faster. Because that teaches us a lot about when it matters. Indeed, IO bound vs CPU bound. The collecting/reducing is CPU and memory juggling-bound the reading of the file IO. that IO part should hardly matter, but the processing is what makes the difference. Ruby is slow here. Rust isn't. Point being: when you are doing a lot of CPU-bound stuff, ruby is probably a bad choice (and Rust a good one). But since in practice of web-services are almost all about IO (and some de/serialization) it matters less there.

2. I too have written PG backed services (in both Rust and Ruby) where database-collection is under 10ms. In a typical SAAS/PAAS setup, however, there will be a network between app and db, adding to latency. Localhost/socket makes it a lot faster, esp. visible on queries that themselves are fast. The main point, however, wasn't the absolute measures, but the relative numbers. When -relatively- your GC halting becomes significant compared to waiting times for the database, then certainly: Ruby is a severe bottleneck. This happened to me often on convoluted (and terrible) rails codebases. Where GC locking was measured in seconds (but where sometimes database queries were measured in tens of seconds).

3. The flamegraph indeed shows that Datetime::parse is the bottleneck in that particular setup. I tried to explain that with:

> The parsing (juggling of data) takes the majority of time: DateTime::parse. Or, reversed: the DateTime::parse is such a performance-hog, that it makes the time spent in the database insignificant.

But I also tried to spend time to explain all the situations in which this is mitigated. Yes! in this case Ruby truly is the bottleneck. But when we move to more wordly cases, these bottlenecks shift towards the database again. E.g. a write-heavy app. Or one that uses complex lookups that return little data.

Again, sorry for the confusion. I guess the title simply doesn't match the actual content of the article very well. Which is more about "when does the bad performance of Ruby, the language, really matter, and when doesn't it". I hoped the intro solved this, but should probably have spend more time on a better title. Sorry.

You are right. And I tried to link to as many relevant previous articles in my article here. Still, I think it is good to keep sharing this. If only because writing a blog-post allows me to organize my thoughts on this ;)

WRT the twitter story: correct. But that conflates Rails with Ruby and it uses a case that is quite exceptional.

Ruby is only a part of why Rails is slow. Rails is mostly slow because of the heavy and poorly optimized reliance on the database (as I argue in the article) and because of it's immensly complicated layering and dataflow. A single DateTime from a database might pass through some thousands of classes and methods before being send off in a body of HTML. Ruby is a problem here, because tousands of times "something rather slow" makes it very slow. But the "thousands of layers" really is a problem in itself. Without rails it could easily be less than hundred and you'll still have a neat architecture and layering and stuff.

The other thing is that no-one except twitter (and maybe three, four other companies) are operating on that kind of scale. At such scale, entirely different metrics start to matter than what we usually encounter on a typical 2000 MAU SAAS product.

But that wasn't the point, really?