Earlier quoted context omitted.
Generally I agree with this thinking, but a number of the idioms in this repo (respond_to? rather than begin/rescue) do have a fairly significant perf benefit and are easier to read. And some of the other lessons, like "don't use method_missing if you can define a method instead", are well worth considering as well.
A minor nitpick: > And some of the other lessons, like "don't use method_missing if you can define a method instead", are well worth considering as well. I'd argue that this one also falls into the category of "simpler/more readable and , incidentally, more performant". When defining methods you get the correct behaviour of respond_to? for free, whereas when overriding method_missing, you also have to take care of de…
Fast Ruby – A collection of common Ruby idioms
21–27 of 27 posts
Re: Fast Ruby – A collection of common Ruby idioms
#22In the "Enumerable#select.last vs Enumerable#reverse.detect" benchmark it would be interesting to know what the result of Enumerable#reverse_each.detect would be.
Re: Fast Ruby – A collection of common Ruby idioms
#23Re: Fast Ruby – A collection of common Ruby idioms
#24What I love about this presentation is that it's not advice -- it's a collection of tools for your perusal. Use at your own discretion. A lot of quote-unquote "high-quality" Ruby code I've seen is either biased towards readability, biased towards extensibility, or sitting somewhere on the edge between the two. So I really do think every Ruby developer should at least glance at this collection and be familiar with it.
Re: Fast Ruby – A collection of common Ruby idioms
#25Don't get me wrong, I think Ruby is a great language and I use it every day to get paid, but it is not a speed queen. Ruby's strengths lie in flexibility, fast iteration, readable code and permitting a functional style.
In most practical web applications the big bottlenecks will be either view rendering or database. Choosing to put any focus at all on performance of something like parallel vs serial assignment (unless you are doing something truly pathological) is a complete waste of time.
It will have no noticeable difference to the end user and distracts from the far more important job of making your code modular, extensible and readable.
If need your code to be fast and you are running Ruby, you already lost. Use Java or a compiled language instead.
Re: Fast Ruby – A collection of common Ruby idioms
#26Re: Fast Ruby – A collection of common Ruby idioms
#27I'm surprised at the speed difference between parallel and sequential assignment styles. I prefer the sequential, so that's a nice bonus that it's also more performant.