Front page | perl.perl5.porters |
Postings from January 2022
Re: PSC #049 2022-01-07
Thread Previous
|
Thread Next
From:
Andrew Hewus Fresh
Date:
January 11, 2022 03:20
Subject:
Re: PSC #049 2022-01-07
Message ID:
Ydz3aj1s4++hlj5G@us.holligan.net
I have no clue at all whether this is possible, so I'm guessing folks
who know have thought of and rejected this. I have not seen that
mentioned (I may have missed it) so I'll ask.
On Mon, Jan 10, 2022 at 06:36:24PM +0000, Paul LeoNerd Evans wrote:
> But now consider some purely-dynamic runtime things that the parser
> could not know about:
>
> no strict 'refs';
> my $sym = "some code here";
> my $val = shift @{$sym};
Would it be possible to detect when some common subset of things was
true that would allow disabling populating @_? For example, strict
enabled, no touching of @_, no "goto" and no "eval". Perhaps some other
disallowed things, but maybe few enough that it would be possible to
mark the sub as "doesn't need @_" and not initialize it for those?
Perhaps this optimization can be separated from signatures completely
and it could speed up:
{ my $n = 0; sub next { ++$n } sub current { $n } }
Sure your examples couldn't be, but maybe the things that could be
detected that don't need @_ is enough to be worth it?
If there was a way to get the argument count without checking @_, and
you could check somehow why your function was not able to get the
optimization, folks could make sure their speed sensitive functions got
it.
--
andrew
Instructions are just another man's opinion of how to do something.
-- Weldboy #DPWisdom
Thread Previous
|
Thread Next