I was recently introduced to the Symbol.to_proc trick where you can
invoke methods on collection elements in a map call with less syntax, as
in:
[“1”, “2”, “3”].map(&:to_i)
While this is very clever looking (albeit potentially harder to read for
Ruby/Rails noobs, which implies a human performance cost), I started
thinking about it and decided this had to be slower than calling methods
directly, as in:
[“1”, “2”, “3”].map {|x| x.to_i}
So I decided to benchmark it to see. My benchmark test shows that
calling the method through the Symbol.to_proc method (at least in this
case) is 8.5X slower than doing the more readable method invocation.
My benchmark code is below. Is it a valid test? And if so, why should
we use Symbol.to_proc unnecessarily when it is such a poor performer?
Thanks,
Wes
==========benchmark code============
#!/usr/bin/ruby
require ‘benchmark’
include Benchmark
LOOP_COUNT = 1_000_000
x = [“1”,“2”,“3”]
bmbm do |test|
test.report(“Method invoke”) do
LOOP_COUNT.times {x.map {|elem| elem.to_i}}
end
test.report(“Symbol.to_proc”) do
LOOP_COUNT.times {x.map(&:to_i)}
end
end
~
Ruby/Rails noobs, which implies a human performance cost), I started
we use Symbol.to_proc unnecessarily when it is such a poor performer?
The good news, I guess, is that it seems to be only about twice as
slow in Ruby 1.9:
Since I was told about this I’ve stopped using symbol to proc in
favour of typing it out. It may use a little bit more time, but that’s
time that my users won’t spend waiting for the page to process.
I’m not thrilled either. I’m indifferent to the idiom itself, so if
there’s much of an admission price I’m unlikely to use it. We’ll see
how it plays out in further versions of 1.9.
David
–
Rails training from David A. Black and Ruby Power and Light:
Advancing With Rails August 18-21 Edison, NJ
Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
My benchmark code is below. Is it a valid test? And if so, why should
we use Symbol.to_proc unnecessarily when it is such a poor performer?
You seem to have reproduced the research of Matz & Co. The next version of Ruby
will implement Symbol.to_proc in C - turning it from a hack into a /de-facto/
keyword.
See my 1.9.0 benchmarks, a few posts back. It’s still (as of then) a
good bit slower than the block version, at least in this test.
David
–
Rails training from David A. Black and Ruby Power and Light:
Advancing With Rails August 18-21 Edison, NJ
Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
My benchmark code is below. Is it a valid test? And if so, why should
we use Symbol.to_proc unnecessarily when it is such a poor performer?
You seem to have reproduced the research of Matz & Co. The next version
of Ruby
will implement Symbol.to_proc in C - turning it from a hack into a
/de-facto/
keyword.
Do you have a guess why? It seems both expressions could resolve to the
same
opcodes…
Isn’t it as simply as two more method calls in the &:to_i case? One
call to Symbol.to_proc and another call to Object.send, in addition to
the actual method call that you want.
When I look at the &: idiom, the only good reason I can think of to use
it would be if you truly needed to invoke a method whose name you didn’t
know until runtime. Even then, I suspect that &: would still be slower,
again, because it inserts another (unnecessary) method call. In the
case of a truly dynamic method invocation, you would probably just use
Object.send, but with &:, you still have to do the call to
Symbol.to_proc before that.
This has been a good way to get me thinking about the potential cost of
the syntactic sugar that we may exploit all the time in Rails.
Whenever you make a design decision there will be tradeoffs.
Symbol#to_proc trades an increase in readability for a decrease in
performance. It’s good to be aware of this when using it. On the other
hand, there are many things in your Rails app that will be orders of
magnitude slower than your uses of Symbol#to_proc, so I wouldn’t
necessarily reject it out of hand on performance grounds alone.
If you’re writing lower level libraries, I would definitely avoid
using Symbol#to_proc. For a Rails app, trying to eek out milliseconds
by replacing Symbol#to_proc with a block is probably a poor
optimization.
When I look at the &: idiom, the only good reason I can think of to use
it would be if you truly needed to invoke a method whose name you didn’t
know until runtime.
Premature optimization is the root of all evil. We cache both our
database hits
and our web pages hits. We value development time enough to not worry
about the
microseconds of each statement we write, so long as they save
mega-seconds of
coding time.
Even then, I suspect that &: would still be slower,
again, because it inserts another (unnecessary) method call. In the
case of a truly dynamic method invocation, you would probably just use
Object.send, but with &:, you still have to do the call to
Symbol.to_proc before that.
I can’t see a problem with making &: into a single operator. Thats how
constructs like x[0] ||= 0 work - the entire sequence from the [ to the
= goes
into an operator, with x, 0, and 0 as arguments.
coding time.
Not all optimization is premature, though, and some is sort of
incidental. Every time you write code one way, it’s a decision not to
write it in n other possible ways. It’s even true that if I write:
s = “string”
I’ve chosen not to write it as:
s = “#{sleep 10; nil}string”
Of course, you could say that doing it that second way would be dumb
and so on. But if you happen to know that =~ is faster than
Regexp#match, or that a block is faster than Symbol#to_proc, then the
choice of the faster one becomes kind of instantaneous. (Unless of
course you have some specific reason to choose the other, like wanting
the MatchData object or wanting to squeeze your code down.)
In other words, we’re always making these choices, and if the way you
choose happens to run faster, that’s not necessarily the root of any
evil
Even then, I suspect that &: would still be slower,
again, because it inserts another (unnecessary) method call. In the
case of a truly dynamic method invocation, you would probably just use
Object.send, but with &:, you still have to do the call to
Symbol.to_proc before that.
I can’t see a problem with making &: into a single operator. Thats how
constructs like x[0] ||= 0 work - the entire sequence from the [ to the = goes
into an operator, with x, 0, and 0 as arguments.
The &obj thing is more general, though. I guess it could be
special-cased for symbols, though then that means weird things like
that you wouldn’t be able to override #to_proc for a symbol (which
might not matter often but isn’t ideal).
David
–
Rails training from David A. Black and Ruby Power and Light:
Advancing With Rails August 18-21 Edison, NJ
Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
Do you have a guess why? It seems both expressions could resolve to the
same
opcodes…
Isn’t it as simply as two more method calls in the &:to_i case? One
call to Symbol.to_proc and another call to Object.send, in addition to
the actual method call that you want.
I believe that’s right (though I haven’t dug into it). Basically, & is
now a unary operator that calls #to_proc on any object that implements
it:
I was recently introduced to the Symbol.to_proc trick where you can
invoke methods on collection elements in a map call with less syntax, as
in:
[“1”, “2”, “3”].map(&:to_i)
While this is very clever looking (albeit potentially harder to read for
Ruby/Rails noobs, which implies a human performance cost), I started
thinking about it and decided this had to be slower than calling methods
directly, as in:
[“1”, “2”, “3”].map {|x| x.to_i}
So I decided to benchmark it to see. My benchmark test shows that
calling the method through the Symbol.to_proc method (at least in this
case) is 8.5X slower than doing the more readable method invocation.
My benchmark code is below. Is it a valid test? And if so, why should
we use Symbol.to_proc unnecessarily when it is such a poor performer?
Thanks,
Wes
==========benchmark code============
#!/usr/bin/ruby
require ‘benchmark’
include Benchmark
LOOP_COUNT = 1_000_000
x = [“1”,“2”,“3”]
bmbm do |test|
test.report(“Method invoke”) do
LOOP_COUNT.times {x.map {|elem| elem.to_i}}
end
test.report(“Symbol.to_proc”) do
LOOP_COUNT.times {x.map(&:to_i)}
end
end
~
Hey wes,
you are testing “invoking explicit blocks” vs “creating a temporary Proc
object and invoking via that”. What is missing here would be “create a
proc once and invoke via that.” This would be the more real-life
approach, because you usually invoke a Proc/block/whatever on a
structure with more than three entries.
Besides, I found a hack that would decrease the runtime overhead of
using Symbol#to_proc, which is to cache the Proc object inside the
symbol:
class Symbol
def to_proc @to_proc ||= Proc.new { |*args| args.shift.send(self, *args) }
end
end
With this I get runtimes only two times the original ones. But I still
don’t know if I should consider that one safe. Do you have any idea on
that?
/eno
I have a post on my blog that goes into that in more detail:
Nearing 13 years later, I’m happy to report that this same benchmark scripts shows that Symbol.to_proc is now slightly faster than using an explicit block in Ruby 2.6.6
