assert: improve deepEqual perf for large input #12849

addaleax · 2017-05-05T09:15:00Z

Use a Map instead of an array for checking previously found
cyclic references.

This reduces complexity for an array-of-objects case from
O(n²) to O(n·log n).

Case from the issue, new output:

2, 3
3, 0
5, 0
8, 4
12, 2
18, 1
27, 4
41, 3
62, 1
93, 3
140, 4
210, 10
315, 5
473, 11
710, 16
1065, 25
1598, 40
2397, 75
3596, 119
5394, 150
8091, 216
12137, 296
18206, 419
27309, 681
40964, 944
61446, 1439
92169, 2424

Fixes: #12842

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

Affected core subsystem(s)

addaleax · 2017-05-05T09:18:04Z

Also, I found some weird behaviour while doing this:

a = {};
assert.deepStrictEqual([a,a], [a,{}]);

This does not throw, but I think it should; do you agree? Would you consider changing it semver-major? If not, I could do it in this PR, otherwise I’ll just wait until after this to avoid conflicts.

cjihrig

LGTM if the CI passes.

mscdex · 2017-05-05T09:19:40Z

lib/assert.js

-  const actualIndex = memos.actual.indexOf(actual);
-  if (actualIndex !== -1) {
-    if (actualIndex === memos.expected.indexOf(expected)) {
+  memos = memos || {


How about instead doing if (!memos) { memos = ... }?

Sure, why not. Updated

targos · 2017-05-05T09:23:41Z

lib/assert.js

-  if (actualIndex !== -1) {
-    if (actualIndex === memos.expected.indexOf(expected)) {
+  if (!memos) {
+    memors = {


fixed, sorry. 😄

targos · 2017-05-05T09:24:57Z

lib/assert.js

+  } else {
+    memos.actual.map.set(actual, memos.actual.position++);
+  }
+  if (memos.expected.map.get(expected) === undefined) {


!memos.expected.map.has(expected)?

addaleax · 2017-05-05T11:34:04Z

CI: https://ci.nodejs.org/job/node-test-commit/9667/

joyeecheung · 2017-05-05T12:02:13Z

lib/assert.js

-    if (actualIndex === memos.expected.indexOf(expected)) {
+  if (!memos) {
+    memos = {
+      actual: { map: new Map(), position: 0 },


How about a WeakMap?

@joyeecheung That thought occurred to me and I couldn’t really find a difference … would there be one? Is that going to be more performant?

@addaleax I think the GC pressure would be smaller after we leave the function because the references don't have be traversed?

@joyeecheung ok, updated :)

refack · 2017-05-05T12:35:14Z

@addaleax I keep being surprised by your energy and dedication 🥇
You could also add an eager chack at https://github.com/nodejs/node/blob/master/lib/assert.js#L408 and only sort if first compare fails. Or if (!(a instanceof Array) || !(b instanceof Array))

addaleax · 2017-05-05T12:37:03Z

@refack That seems like a completely different issue, though? :D

refack · 2017-05-05T12:41:42Z

It fit under the title "assert: improve deepEqual perf for large input". No need to sort keys of arrays. It is an O(n*log(n)) operation.

addaleax · 2017-05-05T12:46:36Z

@refack Arrays can have extra non-indexed properties, too ;) This might not be as easy as you think. If you think you can improve the situation, feel free to experiment and see if you can get a PR together, and I’ll be happy to review.

refack · 2017-05-05T12:53:29Z

Challenge accepted 🖖

Fishrock123 · 2017-05-05T15:22:21Z

a = {};
assert.deepStrictEqual([a,a], [a,{}]);

Imo, no. deepStrictEqual is supposed to make sure the props are strictly equal, not if the object is the same memory address.

Fishrock123

CI again, since the last one only ran linux(?): https://ci.nodejs.org/job/node-test-pull-request/7899/

addaleax · 2017-05-05T19:50:21Z

@joyeecheung Looks like doing this with WeakMaps is a bit more complicated than just switching the Map type, because at that part of the code it’s possible that one of the values is not a primitive (and it’s tricky to fix that because in for non-strict deepEqual a non-primitive and a primitive can compare equal).

New CI: https://ci.nodejs.org/job/node-test-commit/9684/

addaleax · 2017-05-05T19:56:48Z

 a = {};
assert.deepStrictEqual([a,a], [a,{}]);

Imo, no. deepStrictEqual is supposed to make sure the props are strictly equal, not if the object is the same memory address.

Sorry, huh – what do memory addresses have to do with this? It’s not about the left and the right side of assert.deepStrictEqual having different object identities, it’s about different kinds of cyclic structures comparing equal.

To have a more explicit example:

a = {}; b = {};
assert.deepStrictEqual({key1:a,key2:a},{key1:a,key2:b});

should throw imo, because obj1.key1 === obj1.key2 but obj2.key1 !== obj2.key2.

TimothyGu · 2017-05-05T20:32:41Z

lib/assert.js

+
+  const actualPosition = memos.actual.map.get(actual);
+  if (actualPosition !== undefined) {
+    if (actualPosition === memos.expected.map.get(expected)) {


Changing from Array.prototype.indexOf (which uses Strict Equality Comparison) to Map.prototype.get (which uses SameValueZero) can have subtle nuances that might result in incompatibilities, especially around NaN. Not sure if we need to care about it though.

I don’t think that actually affects the logic here – if it matters at all, it should only affect cases where non-primitives compare deep-equal to primitives, but that doesn’t seem to happen anyway (e.g. assert.deepEqual([0], 0) throws even though [0] == 0).

Trott · 2017-05-05T20:52:07Z

a = {}; b = {};
assert.deepStrictEqual({key1:a,key2:a},{key1:a,key2:b});

One more reason to consider the implementation of deep*() in core a mistake and something that should have been left to userland.

IMO, that should not throw (so the current behavior is correct). The deep part of deepStrictEqual() is sorta kinda "hey, I'm recursive!" So it sees an object (or array, and ideally Map or Set too, basically any collection) as the value and is all like, "OK, let's go through this thing's values and see if they're all strict equal! No keys in both objects, they are deep strict equal!"

So, confusingly, the "strict" part doesn't apply to objects (or arrays or--ideally at least--Maps or Sets). It does mean "don't cast a string to a number" though. Whee!

But I do agree it's confusing and unfortunate.

Even if you disagree, I definitely wouldn't fix it in this PR because I predict a CITGM run will not be kind to the additional change.

Trott

Change looks good to me if CI is green and if benchmark/assert doesn't show any perf regressions. (Maybe add a benchmark to show the benefit of this change if existing benchmarks don't already show it?)

refack · 2017-05-06T18:47:48Z

CI (linux only): https://ci.nodejs.org/job/node-test-commit-linux/9688/

joyeecheung · 2017-05-07T09:12:58Z

@addaleax hmm wait, do we even need to put primitives into the memos? The memos are for cycles and is it even possible to make a cycle with primitives? (Or do we even care if they do since they are not compared recursively?)

Also FWIW I think the example above should not throw because objects are not primitives and as the docs and the comments stare, for non-primitives we don't compare them by using operators. Objects with the same properties(or no properties), prototypes and tags should be considered equal.

addaleax · 2017-05-07T19:03:35Z

hmm wait, do we even need to put primitives into the memos? The memos are for cycles and is it even possible to make a cycle with primitives?

I don’t think so, for both questions – but I’m not sure it’s trivial to undo that without changing the logic here for really weird edge cases.

Use a Map instead of an array for checking previously found cyclic references. This reduces complexity for an array-of-objects case from O(n²) to O(n·log n). Fixes: nodejs#12842 PR-URL: nodejs#12849 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

addaleax · 2017-05-07T19:43:12Z

Landed in 7e5f500

Use a Map instead of an array for checking previously found cyclic references. This reduces complexity for an array-of-objects case from O(n²) to O(n·log n). Fixes: #12842 PR-URL: #12849 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

Use a Map instead of an array for checking previously found cyclic references. This reduces complexity for an array-of-objects case from O(n²) to O(n·log n). Fixes: nodejs#12842 PR-URL: nodejs#12849 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>

gibfahn · 2017-06-20T22:33:55Z

@addaleax if this is to be backported to v6.x it would need to be benchmarked on that branch. Feel free to backport or just change the label.

Should this be backported to v6.x-staging? If yes please follow the guide and raise a backport PR, if no let me know or add the dont-land-on label.

nodejs-github-bot added the assert Issues and PRs related to the assert subsystem. label May 5, 2017

addaleax mentioned this pull request May 5, 2017

Comparing arrays with assert seems to take polynomial time. #12842

Closed

mscdex added the performance Issues and PRs related to the performance of Node.js. label May 5, 2017

addaleax requested review from joyeecheung and Trott May 5, 2017 09:18

cjihrig approved these changes May 5, 2017

View reviewed changes

mscdex reviewed May 5, 2017

View reviewed changes

jasnell approved these changes May 5, 2017

View reviewed changes

targos reviewed May 5, 2017

View reviewed changes

addaleax force-pushed the assert-deepequal-map branch from 776351a to 788ac8b Compare May 5, 2017 09:29

addaleax force-pushed the assert-deepequal-map branch from 7664b48 to a60f489 Compare May 5, 2017 11:39

joyeecheung reviewed May 5, 2017

View reviewed changes

joyeecheung approved these changes May 5, 2017

View reviewed changes

refack approved these changes May 5, 2017

View reviewed changes

Fishrock123 approved these changes May 5, 2017

View reviewed changes

TimothyGu reviewed May 5, 2017

View reviewed changes

Trott approved these changes May 5, 2017

View reviewed changes

addaleax force-pushed the assert-deepequal-map branch from 32c658d to bc62437 Compare May 7, 2017 19:24

addaleax closed this May 7, 2017

addaleax deleted the assert-deepequal-map branch May 7, 2017 19:43

jasnell mentioned this pull request May 11, 2017

8.0.0 Release Proposal #12220

Closed

gibfahn mentioned this pull request Jun 15, 2017

Auditing for 6.11.1 nodejs/Release#230

Closed

3 tasks

gibfahn added the backport-requested-v6.x label Jun 20, 2017

addaleax added dont-land-on-v4.x and removed backport-requested-v6.x labels Jun 21, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

assert: improve deepEqual perf for large input #12849

assert: improve deepEqual perf for large input #12849

addaleax commented May 5, 2017

addaleax commented May 5, 2017

cjihrig left a comment

mscdex May 5, 2017

addaleax May 5, 2017

targos May 5, 2017

addaleax May 5, 2017

targos May 5, 2017

addaleax commented May 5, 2017

joyeecheung May 5, 2017

addaleax May 5, 2017

joyeecheung May 5, 2017

addaleax May 5, 2017

refack commented May 5, 2017 •

edited

Loading

addaleax commented May 5, 2017

refack commented May 5, 2017

addaleax commented May 5, 2017

refack commented May 5, 2017

Fishrock123 commented May 5, 2017

Fishrock123 left a comment

addaleax commented May 5, 2017

addaleax commented May 5, 2017

TimothyGu May 5, 2017

addaleax May 5, 2017

Trott commented May 5, 2017

Trott left a comment •

edited

Loading

refack commented May 6, 2017

joyeecheung commented May 7, 2017 •

edited

Loading

addaleax commented May 7, 2017

addaleax commented May 7, 2017

gibfahn commented Jun 20, 2017

assert: improve deepEqual perf for large input #12849

assert: improve deepEqual perf for large input #12849

Conversation

addaleax commented May 5, 2017

Checklist

Affected core subsystem(s)

addaleax commented May 5, 2017

cjihrig left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

addaleax commented May 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

refack commented May 5, 2017 • edited Loading

addaleax commented May 5, 2017

refack commented May 5, 2017

addaleax commented May 5, 2017

refack commented May 5, 2017

Fishrock123 commented May 5, 2017

Fishrock123 left a comment

Choose a reason for hiding this comment

addaleax commented May 5, 2017

addaleax commented May 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Trott commented May 5, 2017

Trott left a comment • edited Loading

Choose a reason for hiding this comment

refack commented May 6, 2017

joyeecheung commented May 7, 2017 • edited Loading

addaleax commented May 7, 2017

addaleax commented May 7, 2017

gibfahn commented Jun 20, 2017

refack commented May 5, 2017 •

edited

Loading

Trott left a comment •

edited

Loading

joyeecheung commented May 7, 2017 •

edited

Loading