op.c: Force shared hash key optimisation for existing COWs
authorFather Chrysostomos <sprout@cpan.org>
Wed, 7 Aug 2013 15:52:23 +0000 (08:52 -0700)
committerFather Chrysostomos <sprout@cpan.org>
Sun, 11 Aug 2013 14:49:56 +0000 (07:49 -0700)
commit54ac81a4f8dd759b88b5a5104af99f6af2814215
treec6229814fa4648c2d23690fc1e4976cf5e42b7a8
parentc9f1f591ba751b24222b22f1f3a6799db0ab0d1b
op.c: Force shared hash key optimisation for existing COWs

If COW scalars are becoming more prevalent (they are), the hash key
optimisation will be less and less likely to kick in if it is skipped
for anything already SvIsCOW.

The assumption is that such a scalar is already a shared hash key sca-
lar.  That is not true for copy-on-write scalars made such by the new
mechanism that allows existing non-COW scalar to be upgraded to such.

The purpose of using shared hash keys scalars here is that the precom-
puted hash is already stored in the scalar (ok, it points to it indi-
rectly), speeding up hash lookup.

New COW scalars don’t have that and offer no speedup here.

So skip the optimisation only when the COW scalar is a shared hash
key scalar.

All of the above applies to methods as well.
op.c