This is shorthand for:
survey.map { |s| s.questions }.flatten.compact
It's the Symbol#to_proc
method. It used to be a part of Rails' ActiveSupport, but has since been added to Ruby syntax.
As far as performance goes, I wrote a quick benchmark script to get an idea of performance effect in both 1.8 and 1.9.
require 'benchmark'
many = 500
a = (1..10000).to_a
Benchmark.bm do |x|
x.report('block once') { a.map { |n| n.to_s } }
x.report('to_proc once') { a.map(&:to_s) }
x.report('block many') { many.times { a.map { |n| n.to_s } } }
x.report('to_proc many') { many.times { a.map(&:to_s) } }
end
First off, before giving you the results - if you weren't already sure that Ruby 1.9 was a huge speed improvement in general, prepare to be blown away.
Ruby 1.8 results:
user system total real
block once 0.020000 0.000000 0.020000 ( 0.016781)
to_proc once 0.010000 0.000000 0.010000 ( 0.013881)
block many 6.680000 1.100000 7.780000 ( 7.780532)
to_proc many 7.370000 0.540000 7.910000 ( 7.902935)
Ruby 1.9 results:
user system total real
block once 0.010000 0.000000 0.010000 ( 0.011433)
to_proc once 0.000000 0.000000 0.000000 ( 0.004929)
block many 4.060000 0.000000 4.060000 ( 4.057013)
to_proc many 2.810000 0.000000 2.810000 ( 2.810312)
First off: Wow. Ruby 1.9 is fast. But the more relevant conclusions we draw here are interesting:
- In both cases, for only one run,
to_proc
is clearly faster. In 1.8 on the many-times run, it's tad slower. This seems to indicate that the only real performance bottleneck is creating all those Proc objects.
- In Ruby 1.9, however, the
to_proc
method is clearly much faster than blocks, no matter how many times you do it. In this case, you not only get cleaner code, but improved performance, as well.
In the end, no matter which version you're using, to_proc
is clearly not enough of a performance issue to be worth not using - in fact, it sometimes speeds things up!
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…