Front page | perl.perl5.porters |
Postings from January 2017
On Tue, Jan 03, 2017 at 01:22:08PM +0000, Dave Mitchell wrote:
> 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.
I've since done this a different way. First I've pushed the following set
of commits to blead:
commit bec5a1ba1ddeb36f189da30307757fead2933e93
Merge: 12e1fa6 b243b19
Author: David Mitchell <davem@iabyn.com>
AuthorDate: Fri Jan 6 16:28:50 2017 +0000
Commit: David Mitchell <davem@iabyn.com>
CommitDate: Fri Jan 6 16:28:50 2017 +0000
[MERGE] redo boolean context
Overhaul the stuff that flags an op as being in boolean context (currently
just padhv and rv2hv). Make the mechanism in rpeep() general, so that
other ops can be easily added in future, and add a generic testing
framework for such ops in t/perf/optree.t.
This alters the amount on situations recognised as being in boolean
context (mainly increasing them).
which fixes some bugs and adds a general framework for supporting boolean-
context ops.
Then I've pushed the following branch as davem/boolref2 which I intend to
merge sometime after 5.26:
commit a83d533d7b264b0df884decfc144af10b79c7f24
Author: David Mitchell <davem@iabyn.com>
AuthorDate: Fri Jan 6 14:59:54 2017 +0000
Commit: David Mitchell <davem@iabyn.com>
CommitDate: Fri Jan 6 16:32:21 2017 +0000
make OP_REF support boolean context
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
This commit builds on the mechanism already used to set the OPpTRUEBOOL
and OPpMAYBE_TRUEBOOL flags on padhv and rv2hv ops when used in boolean
context.
I've had a quick look though our ops list to see what other ops might
benefit from special-case handling in boolean context. There aren't
actually all that many. OP_KEYS and OP_VALUES could probably be tidied up a
bit and length($utf8_string) would probably benefit from not needing to
do a bytes -> chars length conversion. Other than one or two other minor
cases, not a lot leaped out at me. Its possible that ops which return
integer values might be able to do it more efficiently if they just return
PL_sv_yes/no rather than having to set a PADTMP to an integer value.
Anyway, I'll look further into doing other ops after 5.26.
--
"Emacs isn't a bad OS once you get used to it.
It just lacks a decent editor."
Thread Previous
|
Thread Next