develooper Front page | perl.perl5.porters | Postings from January 2022

Re: PSC #049 2022-01-07

Thread Previous | Thread Next
Andrew Hewus Fresh
January 11, 2022 03:20
Re: PSC #049 2022-01-07
Message ID:
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


Instructions are just another man's opinion of how to do something. 
                      -- Weldboy #DPWisdom

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About