streams: refactor getHighWaterMark in state.js#20415
streams: refactor getHighWaterMark in state.js#20415danbev wants to merge 3 commits intonodejs:masterfrom
Conversation
This commit aims to reduce some code duplication in state.js
apapirovski
left a comment
There was a problem hiding this comment.
LGTM. (I would maybe prefer an early if return instead of the nested ternary but either's fine.)
lib/internal/streams/state.js
Outdated
| if (typeof hwm !== 'number' || !(hwm >= 0)) | ||
| throw new ERR_INVALID_OPT_VALUE(duplexKey, hwm); | ||
| return Math.floor(hwm); | ||
| if (typeof hwm !== 'number' || !(hwm >= 0)) { |
There was a problem hiding this comment.
Could we also change hwm >= 0 to hwm < 0? That negation is just confusing, I think.
There was a problem hiding this comment.
That has a different meaning though because it does not catch NaN anymore.
There was a problem hiding this comment.
Good point. In that case maybe we should be checking for that explicitly? The fact that both me and @lpinca missed it means it is likely to get missed again in the future and then no one might correct it.
There was a problem hiding this comment.
Well, hopefully we have tests for it ;-) Besides that, I guess it would be good to add a comment next to it.
There was a problem hiding this comment.
It seems we don't as CI is green for this :)
It wasn't changed yet, sorry.
There was a problem hiding this comment.
I think we have tests actually. @danbev hasn't made the change yet. Anyway, I'm fine with adding a comment. Just not a big fan of non-obvious checks like this.
There was a problem hiding this comment.
Indeed, it would be semver-major but using Number.isInteger() seems the ideal solution.
There was a problem hiding this comment.
Sorry about the delay on this. I'll take a closer look tomorrow (public holiday here today)
lib/internal/streams/state.js
Outdated
| return Math.floor(hwm); | ||
| if (typeof hwm !== 'number' || !(hwm >= 0)) { | ||
| const name = isDuplex ? duplexKey : 'highWaterMark'; | ||
| throw new ERR_INVALID_OPT_VALUE(`options.${name}`, hwm); |
There was a problem hiding this comment.
I don't think the options. bit is necessary? IMO it's more readable without.
There was a problem hiding this comment.
The only reason for making this change was to be consistent with #20284 but I'm happy to remove this.
There was a problem hiding this comment.
The error constructors are different though. This one is more specific since it's not ERR_INVALID_ARG_TYPE but rather ERR_INVALID_OPT_VALUE. Meaning it already communicates that it's within the options object.
|
Nit: subsystem in commit message should be "stream:" not "streams:" |
BridgeAR
left a comment
There was a problem hiding this comment.
I am -0 on this one. If the code is not inligned by V8, it is more work than before and the readability is IMO reduced now.
lib/internal/streams/state.js
Outdated
| if (typeof hwm !== 'number' || !(hwm >= 0)) | ||
| throw new ERR_INVALID_OPT_VALUE(duplexKey, hwm); | ||
| return Math.floor(hwm); | ||
| if (typeof hwm !== 'number' || !(hwm >= 0)) { |
There was a problem hiding this comment.
That has a different meaning though because it does not catch NaN anymore.
|
@danbev Could we perhaps run the streams creation benchmark that was created recently? That might tell us whether this change is detrimental to performance. Seems like a good next step in deciding whether we land this or not. |
Sounds good, I'll run |
|
I ran the following benchmark: $ node benchmark/compare.js --old ./node-master --new ./node-pr-20415 --filter creation.js streams > compare-pr-20415.csv
[00:26:25|% 100| 1/1 files | 60/60 runs | 4/4 configs]: Done
$ cat compare-pr-20415.csv | Rscript benchmark/compare.R
confidence improvement accuracy (*) (**) (***)
streams/creation.js kind='duplex' n=50000000 * 0.63 % ±0.56% ±0.74% ±0.97%
streams/creation.js kind='readable' n=50000000 -0.29 % ±0.40% ±0.53% ±0.69%
streams/creation.js kind='transform' n=50000000 0.14 % ±0.56% ±0.74% ±0.97%
streams/creation.js kind='writable' n=50000000 -0.06 % ±0.61% ±0.81% ±1.06%
Be aware that when doing many comparisions the risk of a false-positive
result increases. In this case there are 4 comparisions, you can thus
expect the following amount of false-positive results:
0.20 false positives, when considering a 5% risk acceptance (*, **, ***),
0.04 false positives, when considering a 1% risk acceptance (**, ***),
0.00 false positives, when considering a 0.1% risk acceptance (***) |
|
Landed in 9b24be1 🎉 |
This commit aims to reduce some code duplication in state.js PR-URL: nodejs#20415 Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
This commit aims to reduce some code duplication in state.js PR-URL: #20415 Reviewed-By: Anatoli Papirovski <apapirovski@mac.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
This commit aims to reduce some code duplication in state.js
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes