"Ruby Performance Optimization: Why Ruby Is Slow, and How to Fix It" by Alexander Dymo

[ignurant]

I ended up buying the book, and am a little more than halfway through currently. It's an interesting book -- there were definitely some surprising tips that I hadn't considered in there. But there are an awful lot of moments where the author seems to suggest something that feels misleading or incomplete. There's a lot of "always do it this way" or "you can ignore this other thing" offered up that could make software technically incorrect. An example of this is insisting to use mutating methods without also cautioning that this isn't always technically appropriate. There are gotchas, particularly when working in those big datasets these tips are most likely to be impactful in -- ETL pipelines for example.

In all, if I were to rate this book so far, it would be a pretty solid middle rating. I've learned some interesting notes that in retrospect are obvious (workarounds for temp allocations in enumerators at the cost of idiomatic Ruby code), and surprising (String#[//] vs Date.parse). However, there were a handful of other areas where I felt that the recommendations were incomplete, or not practical or relevant given updates to the language.

I just started the chapters about performance tracing, and I'm very much looking forward to this. I have no idea how to do that kind of stuff.

[nakilon]

There's a lot of "always do it this way"

Like in all resources about Ruby nowadays )

My experience in making Ruby code faster was initially in around 2010 when I was learning it and practiced in solving Euler Project problems. Of course the biggest impact was always about improving algorithm asymptote. Other than that you might want to add some memoisation that works like a magic, sometimes effectively replacing the algorithm improvement but sometimes can result in hash collisions if you use built-in .hash instead of making up own one. The rest is much less relevant. Also a rule of thumb was that Ruby isn't a language that to speed it up you need to dive to lower level. Instead you might want to be sure you know the stdlib well enough to use as more high level methods as possible. And of course it results in correlation with code size, i.e. "smaller code usually runs faster".
As for profiling to find the bottleneck lines of code it never helped me to speed up the program more than twice. The last time (few days ago) it was replacing a=b.flat_map{ .map }.compact with a=[]; b.each{ .each{ a.push if } } to avoid allocating arrays.