capture - 像 Slurpy 一样使用 Capture

Question

我一直在阅读 Captures这一段引起了我的兴趣:

Inside a Signature, a Capture may be created by prefixing a sigilless parameter with a vertical bar |. This packs the remainder of the argument list into that parameter.

这听起来很像 **@ (非扁平化)slurpy，所以这编造了这个测试代码:

my $limit=1_000_000;
my @a=1 xx 10000;
my @b=-1 xx 10000;

sub test1(|c){
    1;
};

sub test2(**@c){
    1;
};
{ 
    for ^$limit {
        test1(@b,@a);
    }
    say now - ENTER now;
}
{
    for ^$limit {
        test2(@b,@a);
    }
    say now - ENTER now;
}

示例运行给出了每个测试块的持续时间:

0.82560328                                                                                                                                                                                                                                                                                                         
2.6650674 

Capture 似乎具有性能优势。使用 Capture 是否有不利的一面？作为这种时尚的邋遢？我是否过度简化了比较？

Answer 1

Capture 有两个槽，保存 VM 级数组(位置参数)和哈希(命名参数)。它的构造非常便宜，并且 - 由于 |c 样式参数在内部的各个部分中非常常见 - 已经得到了很好的优化。由于捕获参数包含位置参数和命名参数，因此任何命名参数都将被静默忽略。对于方法来说，这可能不是什么大问题，无论如何，不​​需要的命名参数将被默默地放入 %_ 中，但如果在 sub 上使用此构造，则可能是一个考虑因素，因为它不是纯粹的优化:它会改变行为。
**@c 情况分配一个 Array ，然后为每个传递的值分配一个 Scalar 容器，将它们放入 Scalar 容器和那些 Scalar 容器放入 0791046。这是合理数量的额外工作。

这里没有考虑另一种情况，就是这个:

sub test3(**@c is raw){
    1;
}

这将 Array 放在 List 中，并将其元素设置为直接引用传递的内容。这比没有 @c 的情况便宜一点。从理论上讲，它的性能可能与 is raw 之类的捕获参数一样好——如果不是更好的话；它可能只需要有人在编译器上工作才能深入了解为什么还没有。

总之，如果不关心强制逐项和/或传入参数的可变 |c，那么添加 Array 可能是比选择捕获参数更好的优化赌注:参数处理语义更接近，它已经有点快了，将允许用于更自然的代码，并且 future 有可能与 is raw 一样快(如果不是更快)。