Also speed depends on whether the value before the operator evaluates to true i.e. true || false would be faster than false || true as in the first example, the second value does not need checking but it does in the latter.

The inject for empty? is interesting, inject always makes my brain ache even though I’ve been using it for years.

Apologies for the complete lack of formatting.

During benchmarking of a simple string building algorithm, I ended up looking at some of the more minor performance areas, like the boolean operators and functions.

Originally I ‘discovered’ that if/else was faster than the ternary operator; however, further testing revealed this had more to do with specific testing code than anything else.

if true
true
else
false
end

is slower than

true ? true : false

However, their logic are the same.

Further testing (with the help of zenspider, probably more to his annoyance than anything else), I realised that:

if true then true else false end

is effectively the same speed as the ternary operator.

Interesting? Maybe.

Using ‘return’ instead of implicit return values I also found to be slower.

On that note, you can also do this (which clearly isn’t faster, it’s just interesting) (from #ruby-lang):

# 02:38 flgr: interestingly, Array#empty? can be implemented as ary.inject(true) { false }
# 02:39 flgr: what this means is that you can replace ary.empty?() ? a : b with ary.inject(a){ b } all the time
# 02:50 flgr: raggi: you can probably make it faster by using { break b }

N.B. that break, like return, is slightly slower than not doing so, using the tests that I built some time ago, which may need to be re-done.

Analysis of speed at this level is extremely difficult from within the language, and is massively sensitive to environmental influence. It’s almost easier to look at the source and rely on that.

I wasn’t advocating a complete paradigm shift. Just wondered if anyone had come across it before and had noticed any performance gains.

Not really. I’m not in the habit of obfuscating my code to take advantage of minor (it can’t be anything but) performance gains. Also, who’s to say the interpreter won’t change to make the alternate method faster in the future?