Ruby:Proc#call 与 Yield
Ruby 中 thrice
方法的以下两个实现之间的行为差异是什么?
module WithYield
def self.thrice
3.times { yield } # yield to the implicit block argument
end
end
module WithProcCall
def self.thrice(&block) # & converts implicit block to an explicit, named Proc
3.times { block.call } # invoke Proc#call
end
end
WithYield::thrice { puts "Hello world" }
WithProcCall::thrice { puts "Hello world" }
我所说的“行为差异”包括错误处理、性能、工具支持等。
What are the behavioural differences between the following two implementations in Ruby of the thrice
method?
module WithYield
def self.thrice
3.times { yield } # yield to the implicit block argument
end
end
module WithProcCall
def self.thrice(&block) # & converts implicit block to an explicit, named Proc
3.times { block.call } # invoke Proc#call
end
end
WithYield::thrice { puts "Hello world" }
WithProcCall::thrice { puts "Hello world" }
By "behavioural differences" I include error handling, performance, tool support, etc.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我认为第一个实际上是另一个的语法糖。换句话说,不存在行为差异。
第二种形式允许将块“保存”在变量中。然后可以在其他时间点调用该块 - 回调。
好的。这次我做了一个快速基准测试:
结果很有趣:
这表明使用 block.call 几乎比使用 yield 慢 2 倍。
I think the first one is actually a syntactic sugar of the other. In other words there is no behavioural difference.
What the second form allows though is to "save" the block in a variable. Then the block can be called at some other point in time - callback.
Ok. This time I went and did a quick benchmark:
The results are interesting:
This shows that using block.call is almost 2x slower than using yield.
其他答案非常彻底,Closures in Ruby 广泛涵盖了功能差异。我很好奇哪种方法对于可选接受块的方法表现最好,因此我编写了一些基准测试(离开这篇 Paul Mucur 帖子)。我比较了三种方法:
&Proc.new
yield
包装在另一个块中这是代码:
Ruby 2.0.0p247 和 2.0.0p247 之间的性能相似1.9.3p392。以下是 1.9.3 的结果:
在不总是使用时添加显式
&block
参数确实会减慢该方法的速度。如果该块是可选的,请勿将其添加到方法签名中。而且,为了传递块,将yield
包装在另一个块中是最快的。也就是说,这些是一百万次迭代的结果,所以不必太担心。如果一种方法以百万分之一秒为代价使代码更清晰,那么无论如何都要使用它。
The other answers are pretty thorough and Closures in Ruby extensively covers the functional differences. I was curious about which method would perform best for methods that optionally accept a block, so I wrote some benchmarks (going off this Paul Mucur post). I compared three methods:
&Proc.new
yield
in another blockHere is the code:
Performance was similar between Ruby 2.0.0p247 and 1.9.3p392. Here are the results for 1.9.3:
Adding an explicit
&block
param when it's not always used really does slow down the method. If the block is optional, do not add it to the method signature. And, for passing blocks around, wrappingyield
in another block is fastest.That said, these are the results for a million iterations, so don't worry about it too much. If one method makes your code clearer at the expense of a millionth of a second, use it anyway.
如果您忘记传递块,它们会给出不同的错误消息:
但如果您尝试传递“正常”(非块)参数,它们的行为相同:
They give different error messages if you forget to pass a block:
But they behave the same if you try to pass a "normal" (non-block) argument:
我发现结果会有所不同,具体取决于您是否强制 Ruby 构造块(例如预先存在的过程)。
结果如下:
如果将
do_call(&existing_block)
更改为do_call{}
,您会发现两种情况下速度都会慢 5 倍左右。我认为这样做的原因应该是显而易见的(因为 Ruby 被迫为每次调用构造一个 Proc)。I found that the results are different depending on whether you force Ruby to construct the block or not (e.g. a pre-existing proc).
Gives the results:
If you change
do_call(&existing_block)
todo_call{}
you'll find it's about 5x slower in both cases. I think the reason for this should be obvious (because Ruby is forced to construct a Proc for each invocation).顺便说一句,只是为了将其更新到今天,使用:
在 Intel i7(1.5 年前)上。
仍然慢 2 倍。有趣的。
BTW, just to update this to current day using:
On Intel i7 (1.5 years oldish).
Still 2x slower. Interesting.