4 ms·

I'm curious about the performance overhead of this vs using traditional syntax with named variables. Looking over the gem, the code is quite terse, but it depe

I'm curious about the performance overhead of this vs using traditional syntax with named variables. Looking over the gem, the code is quite terse, but it depends on method_missing, which is notoriously slow. The danger with an abstraction like this is that it can make performance problems difficult to identify since it looks so much like a built-in operator. I also agree with stuffihavemade in that I don't actually find (&X.method(bar)) any more clear than { |x| x.method(bar) }

cirwin 14y ago
It's certainly not "free", but as the method_missing calls are all outside of the loop ((0...1000).map(&X.to_s) calls method_missing only once) the impact on code is minimal. I've also found using perftools.rb that it's pretty easy to spot ampex — there was one place where we were using it in a tight nested loop and removing that made a measurable difference over tens of thousands of iterations (just as converting &block parameters to implicit yields makes a measurable difference); but mostly the causes of slowness in our app have not been this.