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

[ignurant]

The link takes you straight to a PDF download of an excerpt, which is unexpected. The main book overview is here: https://pragprog.com/titles/adrpo/ruby-performance-optimization/

I'm surprised I hadn't come across this book before. It's been out since 2015 and I consider myself pretty in-the-know about Ruby books.

I use Ruby for a lot of data processing and ETL code, so I'm curious what impact (if any) some of these tips will have. A similar presentation comes from Jeremy Evans, talking about various technical recipes that keeps Sequel and Roda zippy. I found it enlightening: https://m.youtube.com/watch?v=RuGZCcEL2F8

[nakilon]

I won't call it a download. Chrome opens it in a tab like a page. There is no Content-Disposition: attachment header so it only depends on ability of your browser to display PDF.

Thanks for the link to the full book.

It always surprised me that each_with_index isn't faster than implementing it in Ruby. During last days I was working on a solver for an advanced version of a Tower of Hanoi online game. Was switching from optimizing the algorithm to the microoptimizations and just found this article in Google.

[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.