assert,util: improve deep comparison performance #61076
Conversation
| wellKnownConstructors.add(Float16Array); | ||
| } | ||
| .add(WeakSet) | ||
| .add(Float16Array); |
There was a problem hiding this comment.
It's still behind a flag:
node/deps/v8/src/flags/flag-definitions.h
Lines 331 to 332 in 05f8772
There was a problem hiding this comment.
That seems to just be a legacy part that was not cleaned up in V8. It is fully shipped, V8/Chromium has it enabled as well as all other engines and there is absolutely no way this will be removed again.
I think we should consider it shipped.
There was a problem hiding this comment.
We should remove the flag then
There was a problem hiding this comment.
The property comparison of invalid dates regressed when starting to handle invalid dates as being equal.
This is a very small improvement for error creation.
4f7303b to
641e674
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #61076 +/- ##
=======================================
Coverage 88.52% 88.53%
=======================================
Files 703 703
Lines 208538 208529 -9
Branches 40214 40207 -7
=======================================
+ Hits 184615 184621 +6
- Misses 15921 15925 +4
+ Partials 8002 7983 -19
🚀 New features to boost your workflow:
|
| return false; | ||
| for (const key of getOwnSymbols(val1)) { | ||
| if (hasEnumerable(val1, key)) { | ||
| ArrayPrototypePush(keys1, key); |
There was a problem hiding this comment.
just a sidebar, is this actually faster than keys1[keys1.length] = key;? (i may have asked this before)
There was a problem hiding this comment.
I believe it is the same, while that method is also used before and it is more about the overall logic that should have an impact (less checks for being enumerable needed and no filtering).
| getEnumerables(val2, symbolKeysB).length !== 0) { | ||
| return false; | ||
| } | ||
| for (const key of getOwnSymbols(val2)) { |
There was a problem hiding this comment.
this should probably be a normal for loop (or use SafeArrayIterator)
There was a problem hiding this comment.
This is the same as before and I don't think we should write more non-idiomatic code than absolutely required.
There was a problem hiding this comment.
a normal for loop is quite idiomatic, but sure, if the perf here isn't important then that's fine
This combines minor performance improvements for edge cases as well as adding more tests for partialDeepStrictEqual, resolving a TODO, and fixing a bug while comparing invalid dates (not taking into account that extra properties might exist).
The performance gain is mostly for objects containing symbols. We do not have benchmarks for these and our current benchmarks will not show much difference.
See commit messages for details.