immerjs / immerjs/immer

Immer patches for Array are correct, yet inefficient. Suggesting a new algorithm for optimized patches

Open
#1,052 1 comment 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

proposal
Dominant language
JavaScript
Stars
29k
Forks
881
PR merge metrics
No merged PRs in 30d

Description

I am thinking as offering it as a pull request - let me know what you think

🚀 Feature Proposal

Today when computing a patch on arrays, immer compares objects by index, which results in all array change in case of unshift or splice usage. An example is the following test taken from immer testing -

https://github.com/immerjs/immer/blob/main/__tests__/patch.js#L543-L559

describe("arrays - multiple prepend", () => {
	runPatchTest(
		{x: [1, 2, 3]},
		d => {
			d.x.unshift(4)
			d.x.unshift(5)
			// 4,5,1,2,3
		},
		[
			{op: "replace", path: ["x", 0], value: 5},
			{op: "replace", path: ["x", 1], value: 4},
			{op: "replace", path: ["x", 2], value: 1},
			{op: "add", path: ["x", 3], value: 2},
			{op: "add", path: ["x", 4], value: 3}
		]
	)
})

the expected result should be instead

		[
			{op: "add", path: ["x", 0], value: 5},
			{op: "add", path: ["x", 1], value: 4}
		]

Motivation

I am working on a new framework that also serializes patches, and the above is a performance issue.

Consider the above case - for an array of object, lets say an array of 100 objects with 10 attributes each, the current algorithm will generate 1000 patches, while my suggestion is to produce only 1 per added / removed object

Can this be solved in user-land code?

no

Example

See the example above.

Usage: immer -> serialize -> deserialize -> patched object

suggested algorithm

(pseudo code)

the problem with json diff is that given two arrays, without any additional knowledge, to figure out if an item was
pushed to the front, we have to do a === comparison between the array items, which is O(n^2) complexity.

for (let a = 0; a < A.length; a++) {
    for (let b = 0; b < A.length; b++) {
        if (A[a] === B[b])
            // compute the diff    
    }    
}

However, we can create an algorithm focused on small changes that has complexity O(n) with a cutoff.
The algorithm makes the assumption that small changes can be found fast and require small number of mutations to describe.
The cutoff is set at let limit = log(min(A.length, B.length)) and the algorithm has complexity O(limit^2) ~ O(n)

The algorithm -

let limit = log(min(A.length, B.length));
let a=0, b=0;
mainLoop: while (a < A.length && b < B.length) {
    if (A(a) === B(b)) {
        a += 1;
        b += 1
    }
    continue;
    for (let seekSize = 1; seekSize < limit; seekSize++) {
        for (let index = 1; index <= seekSize; index++) {
            if (A[a+index] === B[b+seekSize-index])
                // we have a match, the elements from A between (a..a+index) and replace them with the items from B between (b..b+seekSize-index)
            continue mainLoop;    
        }
    }
    // revert to direct comparison of attributes json diff model (the standard model used by all other algorithms)
}

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the array patch test in tests/patch.js, especially the "arrays - multiple prepend" case at the referenced lines. Compare its current expected patches with the proposed result, then assess the suggested bounded matching algorithm against prepend, splice, and other array changes. Done means the optimized behavior remains correct while reducing unnecessary patches for small array edits.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, typescript
Domain
performance
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.