develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About