哪个调用效率更高-->在 perl 中转到 &fun($val) 或 fun($val) ?

发布于 2024-12-04 14:26:44 字数 87 浏览 2 评论 0原文

哪种说法更有效 -->在 perl 中转到 &fun($val) 或 fun($val) ? 何时使用哪个语句以获得更好的性能? 请告诉我答案!

Which is more efficient statement --> goto &fun($val) or fun($val) in perl ?
When to use which statement for better performance ?
Please let me know the answer !

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

国际总奸 2024-12-11 14:26:44

我认为这是一个错误的问题。

fun($val) 形式是在 Perl 中调用另一个子例程的标准方法。

goto &func 形式通常用于将控制权转移到另一个子进程,同时删除当前的堆栈帧。此外,@_ 会原封不动地传递给被调用的例程。

删除堆栈帧意味着 caller() 将看不到它,因此 &func 会认为 t 是由执行的例程的调用者调用的转到。这也意味着在调试器中执行回溯不会显示执行 goto 的例程。

如果您想保留调用堆栈帧,但将控制权传递给当前设置为 @_ 的函数,请使用 return &func

goto &func($val) 形式被解析为:

my $label = &func($val);
goto $label;

这可能会给出 Can't find label ... 错误。

示例:

sub func {
  my $x = shift;
  print "x = $x\n";
  my ($package, $file, $line) = caller();
  print "caller file: $file, line: $line\n";
}

sub foo {
  goto &func("from goto bar");
}

sub baz {
  return &func;
}

sub quux {
   goto &func;
}

baz("from baz");
quux("from quux");
foo("from foo");

I think this is the wrong question to ask.

The form fun($val) is the standard way to call another subroutine in perl.

The form goto &func is normally used to transfer control to another sub while removing the current stack frame. In addition, @_ is passed unaltered to the called routine.

The removal of the stack frame means that caller() will not see it, so that the &func will think that t was called by the caller of the routine which performed the goto. It also means that performing a backtrace in the debugger will not reveal the routine performing the goto.

If you want to preserve the calling stack frame but pass control to a function with the current setting of @_, then use return &func.

The form goto &func($val) is parsed as:

my $label = &func($val);
goto $label;

This will likely give a Can't find label ... error.

Examples:

sub func {
  my $x = shift;
  print "x = $x\n";
  my ($package, $file, $line) = caller();
  print "caller file: $file, line: $line\n";
}

sub foo {
  goto &func("from goto bar");
}

sub baz {
  return &func;
}

sub quux {
   goto &func;
}

baz("from baz");
quux("from quux");
foo("from foo");
凡尘雨 2024-12-11 14:26:44

我生命中的惊喜。 no-goto 版本似乎更快。除了深度递归之外,没有什么理由使用除了普通函数调用之外的任何东西。

             Rate with_goto   no_goto
with_goto 56818/s        --      -21%
no_goto   71942/s       27%        --

对此进行了测试:(

use Benchmark ':all';

sub with_goto { $_[0]-- and goto &with_goto }
sub   no_goto { $_[0]-- and      &  no_goto }

cmpthese( 100000, {
  with_goto => '$_=98; with_goto($_)',
    no_goto => '$_=98;   no_goto($_)',
});

仍然感到困惑)

Surprise of my life. The no-goto version seems to be faster. So little reason to use anything else than normal function calls, apart from deep recursion.

             Rate with_goto   no_goto
with_goto 56818/s        --      -21%
no_goto   71942/s       27%        --

Tested with this:

use Benchmark ':all';

sub with_goto { $_[0]-- and goto &with_goto }
sub   no_goto { $_[0]-- and      &  no_goto }

cmpthese( 100000, {
  with_goto => '$_=98; with_goto($_)',
    no_goto => '$_=98;   no_goto($_)',
});

(still baffled)

り繁华旳梦境 2024-12-11 14:26:44

始终使用fun($val)。它更具可读性,并且任何性能差异都足够小,如果这对您很重要,那么您首先就不应该使用 Perl。更不用说 goto 版本可能无论如何都达不到您的预期 - 它们不是同义。

除非您已经对代码进行了分析以确定子例程分派占用了 CPU 周期的很大一部分(极不可能!)并且您已经对代码进行了基准测试来比较这两种方式这样做是为了确保在您的特定情况下,有足够的差异使其发挥作用(甚至可能性更小!),这是一个非常非常不成熟的优化。如果您遇到性能问题,请检查您的算法,而不是担心如此微小的微优化。

Always use fun($val). It's more readable and any performance difference will be small enough that, if it matters to you, then you shouldn't be using Perl in the first place. Not to mention that the goto version probably doesn't do what you intend anyhow - they are not synonymous.

Unless you've already profiled your code to determine that subroutine dispatching is taking up a significant portion of your CPU cycles (highly unlikely that it would be!) and you've benchmarked code to compare the two ways of doing it to ensure that, in your particular case, there is enough of a difference for it to matter (even less likely!), this is a very, very premature optimization. If you're having performance problems, look at your algorithms instead of worrying about such a tiny, tiny microoptimization.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文