Branch: refs/heads/blead
Home: https://github.com/Perl/perl5
Commit: 823fa88ebd51f2c7d55e978d5881cf33e1e64508
https://github.com/Perl/perl5/commit/823fa88ebd51f2c7d55e978d5881cf33e1e64508
Author: Richard Leach <[email protected]>
Date: 2026-07-17 (Fri, 17 Jul 2026)
Changed paths:
M hv.c
Log Message:
-----------
Perl_hv_common - don't call share_hek_flags when (keysv_hek != NULL)
When creating a new `HE` for insertion into a hash that supports shared
keys, `Perl_hv_common` always achieves this via `S_share_hek_flags`.
`S_share_hek_flags` searches the shared string table - `PL_strtab` -
for a matching entry and inserts one if needs be, returning the
relevant `HEK*`.
However, if `Perl_hv_common`'s `keysv` is a "HEK in disguise" to begin
with, `keysv_hek` _already_ contains the resulting `HEK*` - and we
are able to bump the refcount on it. So this commit checks for that
case and branches accordingly.
gcov counts from a perl build and test_harness run suggest that having
a valid `keysv_hek` is already very common.
```
129097943: 996: if (LIKELY(HvSHAREKEYS(hv))) {
129097941: 997: entry = new_HE();
129097941: 998: if (keysv_hek) {
50255991: 999: HeKEY_hek(entry) = keysv_hek;
50255991: 1000: share_hek_hek(keysv_hek);
-: 1001: } else {
78841950: 1002: HeKEY_hek(entry) = share_hek_flags(key, klen, hash,
flags);
-: 1003: }
-: 1004: }
```
If greater use is made of `PL_strtab` in the future, such as for
OP_CONST SVs, the `keysv_hek` is likely to become correspondingly
hotter.
To unsubscribe from these emails, change your notification settings at
https://github.com/Perl/perl5/settings/notifications
