Front page | perl.perl5.porters |
Postings from January 2022
Re: PSC #049 2022-01-07
Thread Previous
|
Thread Next
From:
Ricardo Signes
Date:
January 12, 2022 16:06
Subject:
Re: PSC #049 2022-01-07
Message ID:
1ecc892c-f688-40f5-9d07-5b77a979c6f1@beta.fastmail.com
On Wed, Jan 12, 2022, at 9:20 AM, Paul LeoNerd Evans wrote:
> On Mon, Jan 10, 2022 at 02:46:36PM -0800, Darren Duncan wrote:
> > If it were possible to do in a performant way, my actual preference is for
> > the behavior of signatures to fundamentally be a pretty syntactic shorthand
> > for unpacking "@_" elements into lexicals, and @_ continues to also be
> > available.
>
> Good news - that's exactly how it already works :)
…and let's talk about "performant." That just means "effective" or, often in programming, "fast enough to be acceptable." Are subroutine signatures unacceptably slow? No. The idea that they aren't seems bizarre to me, since they're often *faster than equivalent non-signatured code already.*
Consider* *this program:
use v5.34.0;
use warnings;
use experimental 'signatures';
use Time::HiRes qw(time);
sub sigs ($x) { return $x * $x }
sub bare { my ($x) = @_; return $x * $x }
sub full { die "arity" unless @_ == 1; my ($x) = @_; return $x * $x }
sub million {
my ($name, $code) = @_;
my $before = time;
for (1 .. 1e7) { $code->(1) };
my $after = time;
printf "%s: %0.4fs\n", $name, $after - $before
}
million(sigs => \&sigs);
million(bare => \&bare);
million(full => \&full);
This calls each subroutine 10,000,000 times (despite the name "million"). One has a signature and a tiny body. One copies the argument out of @_. One does that but also checks arity. The more features of signatures you use, the more code you need to compare it to for a fair comparison. But let's start with this statement:
*"sigs" is doing more work and providing more value than "bare", and isn't merely more compact.*
So what's the timing? On my recent Intel MacBook, I routinely get results roughly like this:
sigs: 0.8656s
bare: 1.1357s
full: 1.2632s
The signatures are already faster. Could they be *faster-er* by eliminating @_ setup (and adjusting to some resulting confusion over time)? Yes, I have reason to believe that. But in that scenario we're talking about accelerating our accelerator, not compensating for drag.
--
rjbs
Thread Previous
|
Thread Next