Conversation
nodejs-github-bot
added
assert
BridgeAR
force-pushed
the
improve-assert-performance
branch
from
f72aa63 to
b8451b0
Compare
There was a problem hiding this comment.
Why not do
const tesee = assert[conf.method];Instead of the whole switch?
There was a problem hiding this comment.
Well, the values do change at least partly so we can't just remove the switch. I can combine the ones that have the same arguments if you want me to.
There was a problem hiding this comment.
I think I prefer to stick to the way it is as that way it's simpler to add more tests for the same function with different inputs.
test/parallel/test-assert.js
Outdated
There was a problem hiding this comment.
😄
I'm gonna dig and find how did that happen. Probably an interesting story.
There was a problem hiding this comment.
Not much of a story, it has always been there, nobody notices for 8 years
4f679fd#diff-02063f30815b78f7986ee0c212140b8eR110
|
Quick sanity: https://ci.nodejs.org/job/node-test-commit-linuxone/6915/ |
mscdex
added
the
performance
benchmark/assert/deepequal-buffer.js
Outdated
There was a problem hiding this comment.
nit: unnecessary whitespace changes
There was a problem hiding this comment.
Is it preferred to not use a line break after use strict in general or would you just want to keep that as a separate concern?
|
Not a requirement for landing but helpful if someone has the inclination to run |
|
@Trott I checked the coverage and I was able to remove even more code paths and move another check further up. Now the coverage is back to 100%. So PTAL. Those changes are reflected in these benchmarks: Details[refack: folded benchmark results] |
benchmark/assert/deepequal-buffer.js
Outdated
There was a problem hiding this comment.
@mscdex @nodejs/benchmarking Is this sort of benchmark change OK? Do we usually do changes like this, or do we more typically add additional cases (so n: [1e3, 1e5])?
There was a problem hiding this comment.
Also IMHO even 1e5 is too low for a CPU bound op.
(Some of the p values are too high)
There was a problem hiding this comment.
I'd be tempted to suggest adding as an extra - unless something has been found to be not valid with it being 1e3.
@joyeecheung implemented this benchmark in the first place, was there any particular reason for choosing 1e3 and not a larger number?
The other thing to consider is the length of time to run the benchmark, we should be careful about adding more variants which would add to longer run times for the benchmark suite
There was a problem hiding this comment.
Using different n is not really useful as far as I can tell. And as @refack pointed out using 1e5 is still a low value. Otherwise it's difficult to get a higher significance if I'm correct.
|
I stumbled open a few more tiny improvements (tiny buffers and different sized buffers are checked faster now) and turbofan still can't handle try catch well. |
lib/assert.js
Outdated
refack
left a comment
refack
left a comment
There was a problem hiding this comment.
% /benchmark/ changes decision
lib/assert.js
Outdated
There was a problem hiding this comment.
This is a special case for compatibility so the link to the original PR should be kept IMO
lib/assert.js
Outdated
There was a problem hiding this comment.
Maybe a comment about returning undefined means we need to check further?
benchmark/assert/throws.js
Outdated
There was a problem hiding this comment.
Maybe get rid of the space in the argument values
There was a problem hiding this comment.
Would be a underscore be fine instead? The first part is the function name and that's why I'd like some kind of distinction.
|
Pre-land CI: https://ci.nodejs.org/job/node-test-commit/10890/ |
benjamingr
left a comment
benjamingr
left a comment
There was a problem hiding this comment.
Actual changes LGTM and make a nice improvement - since it changes a lot of code a CITGM run would also be appreciated.
|
@BridgeAR I tried to resolve the conflicts, but it's too delicate. So please rebase. |
The benchmarks had the strict and non strict labels switched. This is fixed and the benchmarks were extended to check more possible input types and function calls.
The lazy loading is not needed as the errors themself lazy load assert. Therefore the circle is working as intended even without this lazy loading. Improve Array, object, ArrayBuffer, Set and Map performance in all deepEqual checks by removing unecessary code paths and by moving expensive checks further back. Improve throws and doesNotThrow performance by removing dead code and simplifying the overall logic.
assert.strictEqual can either have two or three arguments, not four.
BridgeAR
force-pushed
the
improve-assert-performance
branch
from
83a6d77 to
6e456f1
Compare
|
Rebased |
The lazy loading is not needed as the errors themself lazy load assert. Therefore the circle is working as intended even without this lazy loading. Improve Array, object, ArrayBuffer, Set and Map performance in all deepEqual checks by removing unecessary code paths and by moving expensive checks further back. Improve throws and doesNotThrow performance by removing dead code and simplifying the overall logic. PR-URL: nodejs#13973 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
|
@refack Just for context, what’s the motivation for leaving out benchmarks? Anyway, if anything in here can be backported to v8.x, it would need to be backported manually (guide). We’re already in a situation where a lot of changes to |
They were done in this PR to prove it actually has a positive performance gain, but It would perturb https://benchmarking.nodejs.org/ so we spun off #14147 to be discussed just in the context of benchmarking changes. |
|
P.S. should probably land with #14258 |
|
@addaleax I am going to backport this later on. |
|
Lands cleanly now :) |
The lazy loading is not needed as the errors themself lazy load assert. Therefore the circle is working as intended even without this lazy loading. Improve Array, object, ArrayBuffer, Set and Map performance in all deepEqual checks by removing unecessary code paths and by moving expensive checks further back. Improve throws and doesNotThrow performance by removing dead code and simplifying the overall logic. PR-URL: #13973 Reviewed-By: Refael Ackermann <refack@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
11 participants
While refactoring the assert in #13862 I stumbled open a couple of improvements. This change is only about performance changes and not about style.
I added a few more benchmarks and fixed the description of the old ones.
Benchmarks
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
assert