assert: improve partialDeepStrictEqual - #57370
Closed
BridgeAR wants to merge 7 commits into
Closed
Conversation
Collaborator
|
Review requested:
|
Member
Author
|
The new benchmark file somehow can't be applied. Local results (only three stars. I believe I have never had a 500x improvement before :D ) |
Collaborator
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #57370 +/- ##
==========================================
- Coverage 90.23% 90.22% -0.01%
==========================================
Files 630 629 -1
Lines 185211 184976 -235
Branches 36245 36206 -39
==========================================
- Hits 167128 166898 -230
+ Misses 11056 11037 -19
- Partials 7027 7041 +14
🚀 New features to boost your workflow:
|
RafaelGSS
approved these changes
Mar 8, 2025
aduh95
reviewed
Mar 8, 2025
BridgeAR
force-pushed
the
fix-assert-partial-deep-strict-equal
branch
from
March 11, 2025 01:09
bc255c4 to
0a2a533
Compare
aduh95
reviewed
Mar 11, 2025
H4ad
approved these changes
Mar 11, 2025
Member
Author
|
I marked the PR as semver minor due to the removal of the experimental warning. |
Collaborator
BridgeAR
force-pushed
the
fix-assert-partial-deep-strict-equal
branch
from
March 12, 2025 12:09
0a2a533 to
e053279
Compare
Member
Author
|
PTAL. I pushed another change that adds the changed part to the docs, marks a line as unreachable, and updated the examples in the documentation to be on multiple lines to easier read them. |
This significantly improves the assert.partialDeepStrictEqual implementation by reusing the already existing algorithm. It is significantly faster and handles edge cases like symbols identical as the deepStrictEqual algorithm. This is crucial to remove the experimental status from the implementation.
The current settings deactivate the extraProps handling, due to the current implementation failing on these cases.
These benchmarks are not frequently needed and just slow down the default benchmark suite. They are kept for users who want to run them but deactivated by default.
Each file should have a reasonable runtime while having a good accuracy. This adjust those up and down to have minimal runtimes with a good accuracy.
This improves the performance for array comparison by making the sparse array detection simpler. On top of that it adds a fast path for sets and maps that only contain objects as key.
assert.partialDeepStrictEqual now also handled error properties as expected. On top of that, the main implementation also handles non-string `name` and `message` properties and the comparison is a tad faster by removing duplicated comparison steps. As a drive-by fix this also cleans up some code by abstracting code and renaming variables for clarity.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This significantly improves the assert.partialDeepStrictEqual
implementation (see benchmark below) by reusing the already existing algorithm.
It is significantly faster and handles all known edge cases like symbols
identical as the deepStrictEqual algorithm. This is crucial to
remove the experimental status from the implementation.
The old implementation could not yet handle some cases that
the benchmark handles. These are deactivated for now.
This is likely also a good idea due to the significant performance
difference between the two implementations.
I changed the stability index, since it's now handling all cases
properly.
This includes a performance improvement for
assert.deepStrictEqual().A few uncommon cases are actually slower due to seemingly V8
deoptimising the code when hitting rare cases. In reality, that should
not be an issue.
I noticed an interesting thing while working on this.
ObjectPrototypeHasOwnPropertyis significantly faster thanObjectHasOwn. This is something we could take advantageof in other parts of the code and I plan on opening an issue for
V8 to fix that.
Closes #56555