develooper Front page | perl.perl5.porters | Postings from September 2016

Re: Should multideref be disabled if OP_EXISTS/OP_DELETE customcheck functions are set?

Thread Previous
From:
Dave Mitchell
Date:
September 28, 2016 10:34
Subject:
Re: Should multideref be disabled if OP_EXISTS/OP_DELETE customcheck functions are set?
Message ID:
20160928103354.GL3193@iabyn.com
On Mon, Apr 27, 2015 at 09:50:00AM -0300, Vincent Pit (VPIT) wrote:
> 
> 
> Le 27/04/2015 09:31, Dave Mitchell a écrit :
> > On Sat, Apr 25, 2015 at 10:13:54PM -0300, Vincent Pit (VPIT) wrote:
> > > While porting autovivification.pm to the new multideref optimization, I
> > > realized that while the module was loaded the OP_MULTIDEREF ops were
> > > actually pretty rare :
> > [snip]
> > > 
> > > Basically, they only happen for exists and delete constructs, and just for
> > > the last dereferencing. What causes this is this conditional in
> > > S_maybe_multideref() :
> > > 
> > >              /* if something like arybase (a.k.a $[ ) is in scope,
> > >               * abandon optimisation attempt */
> > >              if (  (o->op_type == OP_AELEM || o->op_type == OP_HELEM)
> > >                 && PL_check[o->op_type] != Perl_ck_null)
> > >                  return;
> > > 
> > > This makes a lot of sense, but I wonder if this shouldn't be extended to
> > > topmost OP_EXISTS and OP_DELETE, so that the multideref optimization is also
> > > disabled when they define their own check functions.
> > 
> > Sounds like a good idea, although I'd prefer to leave it until after 5.22
> > 
> 
> Ok, then I'll change it when 5.22 is released.

Now (belatedly) implemented with v5.25.5-44-g81b96c3.

-- 
A power surge on the Bridge is rapidly and correctly diagnosed as a faulty
capacitor by the highly-trained and competent engineering staff.
    -- Things That Never Happen in "Star Trek" #9

Thread Previous


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