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

Re: PSC #049 2022-01-07

Thread Previous | Thread Next
Dave Mitchell
January 19, 2022 11:39
Re: PSC #049 2022-01-07
Message ID:
On Mon, Jan 17, 2022 at 08:41:24PM +0300, Sergey Aleynikov wrote:
> пн, 17 янв. 2022 г. в 15:32, Dave Mitchell <>:
> >
> > 1) leaving @_ untouched when calling a signatured-sub (i.e. it is still
> > the @_ of the caller).
> >
> > This will have a significant performance boost
> While it does, as-is it breaks stack traces. Without stack traces,
> debugging becomes a pain. Unless any proposal for (1) also includes
> solution for stack traces, it makes programmer's life worse, not
> better.

It doesn't necessarily break stack backtraces; that is an entirely
separate choice. It boils down to (on non-@_-setting) sub calls, whether
we leave the original args on the stack or not. At the moment the args are
popped off the stack but stored in @_ instead.

The current behaviour means that for deeply nested sub calls with many
arguments, the stack doesn't tend to grow much, but lots of subs get their
private @_'s AvARRAY array of pointers left grown.

As an extreme example, this code

    sub recurse {
        return if $_[0]-- < 0;
    recurse(10, 1..1_000_000);

would currently:
    expand the stack by 1M pointer sizes (so 8Mb)
    create 10 permanent (but private) @_'s (one for each depth of
    recursion) each with a 1M pointer size buffer that is never freed.

When removing @_, we could either:

1) leave the arguments on the stack:

- this makes @DB::Args continue to work, and changes the memory usage to:
    expand the stack by 10M pointer sizes (80Mb)
    (there are no @_'s using memory)

2) pop the stack after processing args:

- this breaks @DB::Args (and thus stack backtraces), and changes the
  memory usage to:

    expand the stack by 1M pointer sizes (so 8Mb)
    (there are no @_'s using memory)

So we have a complete choice. Leaving the args on the stack (and
thus not breaking stack backtraces) would result in a larger maximum stack
growth (which can then be reused for different sub calls) compared with
now where we have smaller stack growth, but leave lots of @_ buffers
lying around which can only be reused if *those* subs are called again.

This is a great day for France!
    -- Nixon at Charles De Gaulle's funeral

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