Increments

[AiyionPrime]

After fiddling with mendoza patches, I really appreciate the format.

Observing my deltas I found several of my values changing a little over time.
Especially the numeric fields have a rather obvious optimization potential:
Often the numbers do not diff by much.
Maybe a useful addition of ObjectSetFieldValue would be ObjectIncrementFieldValue, which would only allow numeric (not necessarily positive) values as argument.

The differ would compare whether the patch step was shorter if the increment was used instead of set value.

left

{
  "otherbiginfo": "loremipsumdolorsitamet",
  "traffic": {
    "rx": {
      "packets": 652834,
      "bytes": 452876795
    }
  },
  "uptime": 13521.02
}

right

{
  "otherbiginfo": "loremipsumdolorsitamet",
  "traffic": {
    "rx": {
      "packets": 653759,
      "bytes": 452949875
    }
  },
  "uptime": 13579.39
}

Currently a patch for this looks like this (80):

[
  17,
  {
    "rx": {
      "bytes": 452949875,
      "packets": 653759
    }
  },
  "traffic",
  17,
  13579.39,
  "uptime"
]

After implementing
24: Increment
and 25: ObjectIncrementFieldValue

A patch could then look like this (70 chars):

[
  25,
  {
    "rx": {
      "bytes": 73080,
      "packets": 925
    }
  },
  "traffic",
  25,
  58.37,
  "uptime"
]

Looking at ArrayAppendValue and StringAppendString this would be a suitable extension of the current format.
What do you think about this?

[AiyionPrime]

I just translated a real file (971 bytes) using increments and was able to reduce the usual output of mendoza from 587 down to 515 bytes (60% to 53%).

For me this is a promising result, don't you think?

[judofyr]

This is very interesting! We're storing Mendoza patches as binary, which means that we won't save anything particular with this change, but we're transferring it to the browser with JSON and here it would matter.

Introducing these opcodes also means we'll have to think about how we version it. If we add this in e.g. v1.1.0 I'd still like it be able to generates patches which are compatible with v1.0.0. It should probably be an opt-in option.

[AiyionPrime]

[...] We're storing Mendoza patches as binary, which means that we won't save anything particular with this change, [...]

I'm still evaluating the field, may I ask how exactly you store it, that it does not make a difference?
I intend to send them via binary packing them via cbor and even then the suggested addition grants me another 34 bytes compared to throwing mendoza directly through cbor.

[judofyr]

I also realize another thing here: When dealing with objects and arrays it uses the PushField's functionality of keeping track of the field name. This refers to a field by its index instead of the key which typically saves a lot of bytes. In this case it should be possible to use PushField + Value + ReturnIntoObjectSameKey + Pop:

[
  17,
  {
    "rx": {
      "bytes": 452949875,
      "packets": 653759
    }
  },
  "traffic",
  6,
  2,
  0,
  13579.39,
  15
]

If we make a composite key for PushField + Value + ReturnIntoObjectSameKey + Pop:

[
  17,
  {
    "rx": {
      "bytes": 452949875,
      "packets": 653759
    }
  },
  "traffic",
  24,
  2
  13579.39
]