Live data from Hacker News

Fast Ruby – A collection of common Ruby idioms

github.com

21–27 of 27 posts

Re: Fast Ruby – A collection of common Ruby idioms

#21
post #18

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…

Depends on which way you look at it, I think. Like, when building a DSL, I generally take my inputs and do the work up front to use define_method--but I know people who feel that it's simpler to just use method_missing and check against some bit of data here or there. The perf argument isn't going to change their minds overnight, obviously, but I think it helps to make sure you have all the information.

Re: Fast Ruby – A collection of common Ruby idioms

#22
In situations where it's unlikely calling a method will result in a NoMethodError, i prefer rescuing the exception over checking if the method exists first. This will be faster when it does not result in a NoMethodError.

In 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

#24
I like to visualize code quality as a point on a triangle with corners labeled "readable", "extensible", and "performant." Most of what is considered "low-quality" code is biased towards one side of the triangle, and most code quality advice tends towards over-correcting that bias towards another corner of the triangle.

What 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

#25
If you are writing Ruby you already decided you didn't care about speed.

Don'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

#27

I'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.

Hi! Actually the speed difference between parallel and sequential assignment styles was not correct. Please read more details here: https://github.com/JuanitoFatas/fast-ruby/pull/50. Thank you.
Post reply on HN