[ciconia]

Hi, author here. Taking your argument to its logical conclusion we can say that it doesn't matter if your Ruby code is slower or faster because it's Ruby, we know it's "slow-as-molasses", we only care about developer happiness, and anyways we're I/O-bound, so it doesn't really matter how our code performs...

But in my experience it does. I've built platforms in Ruby that handle north of 1K reqs/sec with bursts of 10K reqs/sec on moderate hardware, without needing to setup a whole cluster of machines that crunch on poorly-performing code.

From my experience, getting the average execution time per render from say 0.1ms to 0.01ms, and especially reducing allocations and GC pressure has a big effect on 99% percentiles, and consequently on the cost of compute.

Saying because we use Ruby we don't care if it's slow or not is in a way dismissing it as a viable platform for writing reliable software (because performance is part of reliability).

To me, you can use Ruby to create systems that have very good performance characteristics, and still benefit from developer happiness. The two are not contradictory.

[makeitdouble]

> Taking your argument to its logical conclusion we can say that it doesn't matter if your Ruby code is slower or faster because it's Ruby, we know it's "slow-as-molasses", we only care about developer happiness, and anyways we're I/O-bound, so it doesn't really matter how our code performs...

Not OP, but to a point I think this is pretty much true...

We currently have decent performance so it works out well for most use cases, but if Ruby were to be slower, we could probably cover that issue with infra, caching or other means. As we already do in many cases.

It would be a pain point, but in comparison increasing developer happiness or the whole product dev experience is IMHO a lot harder. Perfs would need to be abysmally bad to change that balance.

[jonhohle]

I’m currently looking at some slow python scripts and libraries that take about 30% of the total build time to generate 20 linker scripts for a project that builds 1,300 C files. Every dev, every build, every CI run is waiting on slow python. So the devs that wrote the tool are happy, but everyone else is slowing dying waiting around for this thing to finish. Relevant [0]

0 - https://www.folklore.org/Saving_Lives.html

[igouy]

Where's the second part of the story: where someone else profiled and discovered 19 of the linker scripts were generated really fast, and that re-working generation of the slowest script only took 15 minutes.

[jonhohle]

I have been profiling and it’s really just python being slow.The first ⅓ of the run of 12 cores is all python. Fortunately these are mostly independent so there is currently no blocking, but there eventually will be.

[igouy]

Thanks. I don't have any expertise to share. I'm just curious. Might PyPy be faster?

[makeitdouble]

> Every dev, every build, every CI run is waiting on slow python.

Parralelize the build, buy more resource for the CI. It might cost more but it will be "saving lifes" after all, right ?

The question is usually whether those scripts would have existed if it wasn't for Python. I assume if it was trivial to rewrite them you'd do it in 2 hours and go on with your life.

[jonhohle]

Besides the python scripts, everything is parallelized and is CPU bound on as many cores as it can be given. Because of licensing throwing more CI at it isn’t an option. This is an open source project, so there’s not really money for buy moar bigger.

The tools possibly wouldn’t exist, but there are options now that provide better ergonomics and are not slow.

[makeitdouble]

I think that's the position most "slow" scripts are: They could have been written faster in the first place, but they weren't intended to be kept for so long and/or that wasn't a priority at all in that moment. And now that people are looking at them again they could be fixed, but there's usually still not enough merits to do so.

I assume something will done at some point, but IMHO it's one of these very nice problems to have, as there is a working version that will only be replaced by something better, and only if it's worth it.

[Lio]

Yep, I agree with this.

Jean Boussier wrote this execellent examination of CPU bound Rails application and why making use of multi-processes is probably a good idea.

Even if you're not using CPU bound it's still daft to leave performance on the table you don't need to.

For the most part if something is a bit slower than it needs to be it still makes more sense to take the obvious bottle necks out before you rewrite the whole system in another language. Especially with YJIT and forcoming ZJIT availible.

1. https://byroot.github.io/ruby/performance/2025/01/23/the-myt...

[richardlblair]

Love all the work Jean Boussier does for the ecosystem.

I would add to this commentary that there are a number of things you can do in Rails to speed it up. For instance, ActionController::Metal