You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
@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.
The section "
begin...rescue
vsrespond_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 thebegin...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, butrespond_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:
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, andrescue
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.The text was updated successfully, but these errors were encountered: