compression: introduce a `storage.revlog.zlib.level` configuration This option control the zlib compression level used when compression revlog chunk. This is also a good excuse to pave the way for a similar configuration option for the zstd compression engine. Having a dedicated option for each compression algorithm is useful because they don't support the same range of values. Using a higher zlib compression impact CPU consumption at compression time, but does not directly affected decompression time. However dealing with small compressed chunk can directly help decompression and indirectly help other revlog logic. I ran some basic test on repositories using different level. I am using the mercurial, pypy, netbeans and mozilla-central clone from our benchmark suite. All tested repository use sparse-revlog and got all their delta recomputed. The different compression level has a small effect on the repository size (about 10% variation in the total range). My quick analysis is that revlog mostly store small delta, that are not affected by the compression level much. So the variation probably mostly comes from better compression of the snapshots revisions, and snapshot revision only represent a small portion of the repository content. I also made some basic timings measurements. The "read" timings are gathered using simple run of `hg perfrevlogrevisions`, the "write" timings using `hg perfrevlogwrite` (restricted to the last 5000 revisions for netbeans and mozilla central). The timings are gathered on a generic machine, (not one of our performance locked machine), so small variation might not be meaningful. However large trend remains relevant. Keep in mind that these numbers are not pure compression/decompression time. They also involve the full revlog logic. In particular the difference in chunk size has an impact on the delta chain structure, affecting performance when writing or reading them. On read/write performance, the compression level has a bigger impact. Counter-intuitively, the higher compression levels improve "write" performance for the large repositories in our tested setting. Maybe because the last 5000 delta chain end up having a very different shape in this specific spot? Or maybe because of a more general trend of better delta chains thanks to the smaller chunk and snapshot. This series does not intend to change the default compression level. However, these result call for a deeper analysis of this performance difference in the future. Full data ========= repo level .hg/store size 00manifest.d read write ---------------------------------------------------------------- mercurial 1 49,402,813 5,963,475 0.170159 53.250304 mercurial 6 47,197,397 5,875,730 0.182820 56.264320 mercurial 9 47,121,596 5,849,781 0.189219 56.293612 pypy 1 370,830,572 28,462,425 2.679217 460.721984 pypy 6 340,112,317 27,648,747 2.768691 467.537158 pypy 9 338,360,736 27,639,003 2.763495 476.589918 netbeans 1 1,281,847,810 165,495,457 122.477027 520.560316 netbeans 6 1,205,284,353 159,161,207 139.876147 715.930400 netbeans 9 1,197,135,671 155,034,586 141.620281 678.297064 mozilla 1 2,775,497,186 298,527,987 147.867662 751.263721 mozilla 6 2,596,856,420 286,597,671 170.572118 987.056093 mozilla 9 2,587,542,494 287,018,264 163.622338 739.803002

     1

A new repository uses zlib storage, which doesn't need a requirement

     2

     3

  $ hg init default

     4

  $ cd default

     5

  $ cat .hg/requires

     6

  dotencode

     7

  fncache

     8

  generaldelta

     9

  revlogv1

    10

  sparserevlog

    11

  store

    12

  testonly-simplestore (reposimplestore !)

    13

    14

  $ touch foo

    15

  $ hg -q commit -A -m 'initial commit with a lot of repeated repeated repeated text to trigger compression'

    16

  $ hg debugrevlog -c | grep 0x78

    17

      0x78 (x)  :   1 (100.00%)

    18

      0x78 (x)  : 110 (100.00%)

    19

    20

  $ cd ..

    21

    22

Unknown compression engine to format.compression aborts

    23

    24

  $ hg --config experimental.format.compression=unknown init unknown

    25

  abort: compression engine unknown defined by experimental.format.compression not available

    26

  (run "hg debuginstall" to list available compression engines)

    27

  [255]

    28

    29

A requirement specifying an unknown compression engine results in bail

    30

    31

  $ hg init unknownrequirement

    32

  $ cd unknownrequirement

    33

  $ echo exp-compression-unknown >> .hg/requires

    34

  $ hg log

    35

  abort: repository requires features unknown to this Mercurial: exp-compression-unknown!

    36

  (see https://mercurial-scm.org/wiki/MissingRequirement for more information)

    37

  [255]

    38

    39

  $ cd ..

    40

    41

#if zstd

    42

    43

  $ hg --config experimental.format.compression=zstd init zstd

    44

  $ cd zstd

    45

  $ cat .hg/requires

    46

  dotencode

    47

  exp-compression-zstd

    48

  fncache

    49

  generaldelta

    50

  revlogv1

    51

  sparserevlog

    52

  store

    53

  testonly-simplestore (reposimplestore !)

    54

    55

  $ touch foo

    56

  $ hg -q commit -A -m 'initial commit with a lot of repeated repeated repeated text'

    57

    58

  $ hg debugrevlog -c | grep 0x28

    59

      0x28      :  1 (100.00%)

    60

      0x28      : 98 (100.00%)

    61

    62

  $ cd ..

    63

    64

Specifying a new format.compression on an existing repo won't introduce data

    65

with that engine or a requirement

    66

    67

  $ cd default

    68

  $ touch bar

    69

  $ hg --config experimental.format.compression=zstd -q commit -A -m 'add bar with a lot of repeated repeated repeated text'

    70

    71

  $ cat .hg/requires

    72

  dotencode

    73

  fncache

    74

  generaldelta

    75

  revlogv1

    76

  sparserevlog

    77

  store

    78

  testonly-simplestore (reposimplestore !)

    79

    80

  $ hg debugrevlog -c | grep 0x78

    81

      0x78 (x)  :   2 (100.00%)

    82

      0x78 (x)  : 199 (100.00%)

    83

    84

#endif

    85

    86

checking zlib options

    87

=====================

    88

    89

  $ hg init zlib-level-default

    90

  $ hg init zlib-level-1

    91

  $ cat << EOF >> zlib-level-1/.hg/hgrc

    92

  > [storage]

    93

  > revlog.zlib.level=1

    94

  > EOF

    95

  $ hg init zlib-level-9

    96

  $ cat << EOF >> zlib-level-9/.hg/hgrc

    97

  > [storage]

    98

  > revlog.zlib.level=9

    99

  > EOF

   100

   101

   102

  $ commitone() {

   103

  >    repo=$1

   104

  >    cp $RUNTESTDIR/bundles/issue4438-r1.hg $repo/a

   105

  >    hg -R $repo add $repo/a

   106

  >    hg -R $repo commit -m some-commit

   107

  > }

   108

   109

  $ for repo in zlib-level-default zlib-level-1 zlib-level-9; do

   110

  >     commitone $repo

   111

  > done

   112

   113

  $ $RUNTESTDIR/f -s */.hg/store/data/*

   114

  zlib-level-1/.hg/store/data/a.i: size=4146

   115

  zlib-level-9/.hg/store/data/a.i: size=4138

   116

  zlib-level-default/.hg/store/data/a.i: size=4138

   117

   118

Test error cases

   119

   120

  $ hg init zlib-level-invalid

   121

  $ cat << EOF >> zlib-level-invalid/.hg/hgrc

   122

  > [storage]

   123

  > revlog.zlib.level=foobar

   124

  > EOF

   125

  $ commitone zlib-level-invalid

   126

  abort: storage.revlog.zlib.level is not a valid integer ('foobar')

   127

  abort: storage.revlog.zlib.level is not a valid integer ('foobar')

   128

  [255]

   129

   130

  $ hg init zlib-level-out-of-range

   131

  $ cat << EOF >> zlib-level-out-of-range/.hg/hgrc

   132

  > [storage]

   133

  > revlog.zlib.level=42

   134

  > EOF

   135

   136

  $ commitone zlib-level-out-of-range

   137

  abort: invalid value for `storage.revlog.zlib.level` config: 42

   138

  abort: invalid value for `storage.revlog.zlib.level` config: 42

   139

  [255]

   140