"begin...rescue vs respond_to? for Control Flow" inaccurate if method exists

[jrunning]

The section "begin...rescue vs respond_to? for Control Flow" is correct when the receiver does not respond to the method (because rescuing an exception is expensive), but when the receiver does respond to the method the begin...rescue idiom is much faster—in my tests about 15x faster. This makes sense since, if the method does exist, begin...rescue has no overhead, but respond_to? has the overhead of an additional method call whether the method exists or not.

You can see my tests and their results here: https://gist.github.com/jrunning/0e18236c6363af15c520 I tested a number of different scenarios: implicit receiver ("LocalVariableOrMethod"), explicit receiver, a long inheritance chain, and implicit receiver with "global" methods, but in all cases it was pretty much the same:

Comparison:
test_rescue_global_does_exist:  7198903.1 i/s
test_respond_to_global_doesnt_exist:  4493565.9 i/s - 1.60x slower
test_respond_to_global_does_exist:  4476828.4 i/s - 1.61x slower
test_rescue_global_doesnt_exist:   440868.3 i/s - 16.33x slower

In other words, rescue is fastest when the method does exist, respond_to? is 1.42–1.71x slower whether the method exists or not, and rescue is 16–18x slower when the method doesn't exist.

In light of this I think it's harder to give definitive advice on rescue vs. respond_to?. If someone is looking for the fastest idiom then it depends on whether they think the method is more likely to exist or not to exist.

[nirvdrum]

I realize this project has a definite MRI slant to it, but I'd be remiss if I didn't mention that JRuby+Truffle can essentially compile away the respond_to? call by caching the interior method lookup. It's basically multi-dimensional inline cache and at that point, you get all the speculative optimizations that an inline cache affords. I presented the work at the 2015 RubyKaigi with the intention of getting MRI to adopt a similar mechanism for fast metaprogramming.

Apologies if this looks like I'm highjacking the thread. I guess I'm just suggesting there's yet another variable that influences the results on alternative implementations and may influence MRI in a future release.

[jrunning]

@nirvdrum I think that's definitely relevant, though I don't know if this project's maintainers would agree. If it's possible to make Travis run JRuby+Truffle I'd definitely +1 a PR to add it to the .travis.yml.

[mateusdeap]

For now we're trying to tidy up the project, but we can definitely look into providing benchmarks using other ruby implementations.

Closing this since the PR has been merged.