On Sat, Dec 31, 2016 at 04:09:30PM -0800, James E Keenan via RT wrote: > On Fri, 08 Oct 2010 13:29:35 GMT, timbo wrote: > > > > This is a bug report for perl from Tim.Bunce@pobox.com, > > generated with the help of perlbug 1.39 running under perl 5.12.2. > > > > > > ----------------------------------------------------------------- > > [Please describe your issue here] > > > > [16:05] timbunce: code like "if ref $foo" is far more expensive than > > it needs to be because ref() still creates a new SVPV when called in a > > boolean context. > > [16:08] xdg: timbunce, could you please open a ticket on that? I'm > > sure someone can optimize that. > > [16:10] • Nicholas wonders if "if ref $foo" can be spotted with much > > the same code as "if %hash" is > > [16:10] Zefram: yes it can, at op check time > > [16:11] timbunce: How can internals determine "boolean context"? > > [16:11] vincent: at op check time > > [16:11] timbunce: there are probably other ops that could do less work > > in boolean context > > [16:11] Nicholas: offhand, "I don't know", but I know that "if %hash" > > does this > > > > [16:11] Zefram: but ref($foo)'s truth value isn't as simple as most > > people expect, so it's approximately never what a programmer actually > > wants > > [16:12] timbunce: Zefram: true, but that doesn't stop people writing > > "if ref $foo" often > > [16:13] Zefram: I'd be more inclined to use check-time logic to emit a > > warning for it > > [16:14] Zefram: "Dubious use of reference-type operator in truth-value > > context" > > [16:14] timbunce: Zefram: I think you'd have angry hordes after you. > > [16:14] timbunce: better done in perlcritic > > [16:14] PerlJam: timbunce: +1 > > [16:14] mst: Zefram: but then Scalar::Defer won't work anymore > > [16:14] Zefram: Scalar::Defer is an abomination > > [16:15] mst: Zefram: an abomination that's heavily used in the > > pumpking's production code > > [16:16] timbunce: mst Zefram: I think Scalar::Defer could still work. > > The pp_ref code just needs to know if it should return sv_yes or sv_no > > > > In boolean context, pp_ref would check the pv returned by sv_reftype > > in > > the same way that SvTRUE does (for "" and "0") and the push &sv_yes or > > &sv_no. > > > > Tim Bunce proposed this approach more than six years ago. > > Can anyone respond? I've just pushed the commit shown below as davem/boolref. It shows that the concept is sound, but I suggest not merging into blead until after 5.26.0 is released: even just setting an extra private flag on an op may require various B-ish CPAN modules to be updated. The repeep() code in my commit is separate from similar code that puts rv2hv into boolean context in things like if (%h) {...}. I suspect they want merging into a single function. I also noticed there's a bug in the rv2hv stuff: if (!%h) {...} *doesn't* get optimised. I'm open to suggestions for other ops which could benefit from being special-cased in boolean context. commit 9108e50fd89a88637207002130946c9c0b0ecc9d Author: David Mitchell <davem@iabyn.com> AuthorDate: Tue Jan 3 12:08:08 2017 +0000 Commit: David Mitchell <davem@iabyn.com> CommitDate: Tue Jan 3 13:15:42 2017 +0000 add an OPpREF_BOOL flag to OP_REF RT #78288 When ref() is used in a boolean context, it's not necessary to return the name of the package which an object is blessed into; instead a simple truth value can be returned, which is faster. Note that it has to cope with the subtlety of an object blessed into the class "0", which should return false. Porting/bench.pl shows for the expression !ref($r), approximately: unchanged for a non-reference $r doubling of speed for a reference $r tripling of speed for a blessed reference $r I haven't attempted to use a provisional boolean flag for when the expression's context isn't known at compile time (e.g. when used in the last expression in a sub), unlike the similar mechanism for rv2hv etc which has both OPpTRUEBOOL and OPpMAYBE_TRUEBOOL flags. -- Fire extinguisher (n) a device for holding open fire doors.Thread Previous | Thread Next