Groups | Search | Server Info | Login | Register

Groups > perl.perl5.changes > #34446

[Perl/perl5] b3f68b: Convert OP_CONST hash keys in key+val lists to HEKs

Show all headers | View raw

  Branch: refs/heads/blead
  Home:   https://github.com/Perl/perl5
  Commit: b3f68b479c9876437620503fb7d54e14bceadcee
      https://github.com/Perl/perl5/commit/b3f68b479c9876437620503fb7d54e14bceadcee
  Author: Richard Leach <richardleach@users.noreply.github.com>
  Date:   2026-03-10 (Tue, 10 Mar 2026)

  Changed paths:
    M embed.fnc
    M embed.h
    M lib/B/Deparse.t
    M op.c
    M opcode.h
    M proto.h
    M regen/op_private
    M regen/opcodes

  Log Message:
  -----------
  Convert OP_CONST hash keys in key+val lists to HEKs

Hash operations in perl are faster when operating upon a `keysv` that
uses a `HEK` to represent the key. Hash entry comparisons can then be
more lightweight as `HEK` pointer comparisons can be used instead of:
* Re-deriving the hash each time the key is used
* Exhaustive comparison of the hash key values and flags

Some `OP_CONST` SVs that are destined for use as hash keys are already
converted (_hekified_) during compilation, such as the arguments to
`OP_HELEM`, `OP_MULTIDEREF`, or `OP_HSLICE`/`OP_KVSLICE`.
`Perl_check_hash_fields_and_hekify`, which operates on sequential SV
pointers, does the work in those cases.

This commit _hekifies_ `OP_CONST` SV keys - providing they are `SvPOK`
and therefore not subject to locale-specific coercion at run time -
in key+value `SV*` lists, such as in the arguments to `OP_ANONHASH`:

    my $href = { one => 1, two => 2, three => 3, four => 4 };

and `OP_AASSIGN` (note: may not cover all possible LVALUE constructions):

    my %h = ( one => 1, two => 2, three => 3, four => 4 );

`OP_CONST` SVs in the value positions are not _hekified_, as the process
involves attempted downgrade of UTF8 strings, which could result in
user-visible behaviour changes (such as in the comparison of string contents).

For this reason, this optimization returns early when either key or
value OPs have the potential to return more than one value - it becomes
impossible to be sure at compile time whether subsequent OPs represent
keys or values.

As a contrived example: in the following statement, the compiler
cannot be _absolutely_ sure that 'three' will be used as as a key
and `3` is its matching value.

    my $h = (one => 1, @two, three => 3, @four);

Changes in this commit are:
* Addition of the `S_check_alt_hash_fields_hekify` function
* Addition of dedicated `ck` functions for `anonhash` and `aassign`

Comparing `for (0..100_000_000) { my %h = (one => 1, two => 2, three => 3, four => 4); }`:

*Blead*
```
         20,409.44 msec task-clock                       #    1.000 CPUs utilized
               117      context-switches                 #    5.733 /sec
                 0      cpu-migrations                   #    0.000 /sec
               190      page-faults                      #    9.309 /sec
    93,850,595,514      cycles                           #    4.598 GHz
   354,784,740,965      instructions                     #    3.78  insn per cycle
    73,658,057,571      branches                         #    3.609 G/sec
        51,196,358      branch-misses                    #    0.07% of all branches
```
*Patched*
```
         15,295.49 msec task-clock                       #    1.000 CPUs utilized
                79      context-switches                 #    5.165 /sec
                 1      cpu-migrations                   #    0.065 /sec
               195      page-faults                      #   12.749 /sec
    70,493,543,069      cycles                           #    4.609 GHz
   272,426,451,548      instructions                     #    3.86  insn per cycle
    55,406,135,074      branches                         #    3.622 G/sec
       100,887,629      branch-misses                    #    0.18% of all branches
```

Comparing `for (0..100_000_000) { my $h = {one => 1, two => 2, three => 3, four => 4}; }`

*blead*
```
         21,088.71 msec task-clock                       #    1.000 CPUs utilized
               100      context-switches                 #    4.742 /sec
                 2      cpu-migrations                   #    0.095 /sec
               195      page-faults                      #    9.247 /sec
    97,377,416,887      cycles                           #    4.618 GHz
   376,434,236,222      instructions                     #    3.87  insn per cycle
    81,607,926,506      branches                         #    3.870 G/sec
         1,159,167      branch-misses                    #    0.00% of all branches
```
*patched*
```
         16,150.16 msec task-clock                       #    1.000 CPUs utilized
                79      context-switches                 #    4.892 /sec
                 0      cpu-migrations                   #    0.000 /sec
               193      page-faults                      #   11.950 /sec
    74,465,581,333      cycles                           #    4.611 GHz
   298,176,803,158      instructions                     #    4.00  insn per cycle
    63,656,208,147      branches                         #    3.942 G/sec
        50,869,763      branch-misses                    #    0.08% of all branches
```

Note: This will stack with [GH #24149], which reduced branch-misses.


  Commit: 23045b021a96bec42a6510c41d695d90411d23af
      https://github.com/Perl/perl5/commit/23045b021a96bec42a6510c41d695d90411d23af
  Author: Richard Leach <richardleach@users.noreply.github.com>
  Date:   2026-03-10 (Tue, 10 Mar 2026)

  Changed paths:
    M pod/perldelta.pod

  Log Message:
  -----------
  Perldelta entry for GH#24228


Compare: https://github.com/Perl/perl5/compare/e754582d735a...23045b021a96

To unsubscribe from these emails, change your notification settings at https://github.com/Perl/perl5/settings/notifications

Back to perl.perl5.changes | Previous | Find similar

Thread

[Perl/perl5] b3f68b: Convert OP_CONST hash keys in key+val lists to HEKs perl5-changes@perl.org (Richard Leach via perl5-changes) - 2026-03-10 16:47 -0700

csiph-web