This also allows us to remove backslash escaping for `[` and `]`
inside of header code, which makes the bare markdown more readable.
Refs: https://github.com/nodejs/node/pull/31086
PR-URL: https://github.com/nodejs/node/pull/31149
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Currently we only consider write when benchmarking.
PR-URL: https://github.com/nodejs/node/pull/31066
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
adds clear connections to the secure-pair performance test to prove
that in some cases (when the sender send the data in small chunks)
clear connections perform worse than TLS connections
Also add a byte chunk size test to benchmark/net/net-pipe.js
Refs: https://github.com/nodejs/node/issues/27970
PR-URL: https://github.com/nodejs/node/pull/27971
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Make manywrites benchmark a bit more realistic by
taking back pressure into account. Otherwise
memory usage would no correspond well with
real world usage.
PR-URL: https://github.com/nodejs/node/pull/30977
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
* Let users provide more than one pattern by repeating the flag
* Add new flag --exclude to exclude patterns
* Add tests for --filter
* Document --filter
This commit also fixes a bug where things like
`compare.js --new --old binary --new binary` was acceptable (now the
script will exit and print the usage message).
PR-URL: https://github.com/nodejs/node/pull/29987
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This makes sure we do not retrieve the handler in case it's not
required. This improves the performance a tiny bit for these cases.
PR-URL: https://github.com/nodejs/node/pull/30767
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This adds a couple of benchmarks to check different options and code
paths.
PR-URL: https://github.com/nodejs/node/pull/30767
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
The doc/guides directory looks like a place for guides to using Node.js
but it's actually where we store development/internal documentation.
Move the benchmark guide to the benchmark directory where someone (who
doesn't know that bit of somewhat-surprising information) is more likely
to find it.
PR-URL: https://github.com/nodejs/node/pull/30781
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Improve performance and reduce memory usage when a writable stream
is written to with the same callback (which is the most common case)
and when the write operation finishes synchronously (which is also
often the case).
confidence improvement accuracy (*) (**) (***)
streams/writable-manywrites.js sync='no' n=2000000 0.99 % ±3.20% ±4.28% ±5.61%
streams/writable-manywrites.js sync='yes' n=2000000 *** 710.69 % ±19.65% ±26.47% ±35.09%
Refs: https://github.com/nodejs/node/issues/18013
Refs: https://github.com/nodejs/node/issues/18367
PR-URL: https://github.com/nodejs/node/pull/30710
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Upcoming lint rule will require a blank line between consecutive
functions. Add it in the places where we don't have it already.
PR-URL: https://github.com/nodejs/node/pull/30696
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Add an `serialization` option that allows child process IPC to
use the (typically more powerful) V8 serialization API.
Fixes: https://github.com/nodejs/node/issues/10965
PR-URL: https://github.com/nodejs/node/pull/30162
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Warn when a non-existent property of an unfinished module.exports
object is being accessed, as that very often indicates the presence
of a hard-to-detect and hard-to-debug problem.
This mechanism is only used if `module.exports` is still a
regular object at the point at which the second, circular `require()`
happens.
The downside is that, temporarily, `module.exports` will have a
prototype other than `Object.prototype`, and that there may
be valid uses of accessing non-existent properties of unfinished
`module.exports` objects.
Performance of circular require calls in general is not
noticeably impacted.
confidence improvement accuracy (*) (**) (***)
module/module-loader-circular.js n=10000 3.96 % ±5.12% ±6.82% ±8.89%
Example:
$ cat a.js
'use strict';
const b = require('./b.js');
exports.fn = () => {};
$ cat b.js
'use strict';
const a = require('./a.js');
a.fn();
$ node a.js
(node:1617) Warning: Accessing non-existent property 'fn' of module exports inside circular dependency
/tmp/b.js:4
a.fn();
^
TypeError: a.fn is not a function
at Object.<anonymous> (/tmp/b.js:4:3)
[...]
PR-URL: https://github.com/nodejs/node/pull/29935
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Add an option that controls the size of the internal
buffer.
Fixes: https://github.com/nodejs/node/issues/29941
PR-URL: https://github.com/nodejs/node/pull/30114
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Prepare the final few documents that haven't been updated to always use
`[]` with reference links and to escape `[` and `]` for things that
aren't links in markdown files.
PR-URL: https://github.com/nodejs/node/pull/29963
Reviewed-By: Masashi Hirano <shisama07@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Since worker threads are complete Node.js environments, including the
ability to load native addons, and since those native addons can
allocate resources to be freed when objects go out of scope, and since,
upon worker thread exit, the engine does not invoke the weak callbacks
responsible for freeing resources which still have references, this
modification introduces tracking for weak references such that a list
of outstanding weak references is maintained. This list is traversed
during environment teardown. The callbacks for the remaining weak
references are called.
This change is also relevant for Node.js embedder scenarios, because in
those cases the process also outlives the `node::Environment` and
therefore weak callbacks should also be rendered as environment cleanup
hooks to ensure proper cleanup after native addons. This changes
introduces the means by which this can be accomplished.
A benchmark is included which measures the time it takes to execute the
weak reference callback for a given number of weak references.
Re: https://github.com/tc39/proposal-weakrefs/issues/125#issuecomment-535832130
PR-URL: https://github.com/nodejs/node/pull/28428
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
This improves dgram performance by avoiding unnecessary async
operations.
One issue with this commit is that it seems hard to actually create
conditions under which the fallback path to the async case is
actually taken, for all supported OS, so an internal CLI option
is used for testing that path.
Another caveat is that the lack of an async operation means
that there are slight timing differences (essentially `nextTick()`
rather than `setImmediate()` for the send callback).
PR-URL: https://github.com/nodejs/node/pull/29832
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Benchmark different types of operations and make results comparable
by normalizing process.env for enumeartion.
PR-URL: https://github.com/nodejs/node/pull/29188
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
A lot of strings that are going to be passed to `getStringWidth()`
are ASCII strings, for which the calculation is rather easy and
calling into C++ can be skipped.
confidence improvement accuracy (*) (**) (***)
misc/getstringwidth.js n=100000 type='ascii' *** 328.99 % ±21.73% ±29.25% ±38.77%
misc/getstringwidth.js n=100000 type='emojiseq' 2.94 % ±7.66% ±10.19% ±13.26%
misc/getstringwidth.js n=100000 type='fullwidth' 4.70 % ±5.64% ±7.50% ±9.76%
PR-URL: https://github.com/nodejs/node/pull/29301
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
These are rendered as single breaks.
Addresses Markdownlint MD012 rule.
PR-URL: https://github.com/nodejs/node/pull/29352
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Co-Authored-By: Anna Henningsen <anna@addaleax.net>
PR-URL: https://github.com/nodejs/node/pull/25436
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Many benchmarks use test/common/tmpdir. This changes 3 benchmarks that
use NODE_TMPDIR to also use test/common/tmpdir.
This is necessary in preparation for the next commit that changes tmpdir
to delete tmpdir.path when the Node.js process exits. Thus, if multiple
benchmarks are run sequentially, the ones that use tmpdir will remove
the directory and the ones changed here would fail because it does not
exist. This happens when running test/benchmark.
Note: to explicitly select a directory for tmpdir, use NODE_TEST_DIR.
PR-URL: https://github.com/nodejs/node/pull/28858
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
In benchmark http directory this changes for loops using var to let
when it applies for consistency
PR-URL: https://github.com/nodejs/node/pull/28791
Reviewed-By: Rich Trott <rtrott@gmail.com>
In benchmark buffers directory this changes for loops using var to let
when it applies for consistency
PR-URL: https://github.com/nodejs/node/pull/28867
Reviewed-By: Jan Krems <jan.krems@gmail.com>
Reviewed-By: Khaidi Chu <i@2333.moe>
Reviewed-By: Rich Trott <rtrott@gmail.com>
In benchmark util directory this changes for loops using var to let
when it applies for consistency
PR-URL: https://github.com/nodejs/node/pull/28867
Reviewed-By: Jan Krems <jan.krems@gmail.com>
Reviewed-By: Khaidi Chu <i@2333.moe>
Reviewed-By: Rich Trott <rtrott@gmail.com>
In benchmark url directory this changes for loops using var to let
when it applies for consistency
PR-URL: https://github.com/nodejs/node/pull/28867
Reviewed-By: Jan Krems <jan.krems@gmail.com>
Reviewed-By: Khaidi Chu <i@2333.moe>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This updates eslint from v6.0.0-alpha.2 to v6.0.1
This also removes eslint-disable comments about `bigint` typeof
checks. Those would otherwise have caused linting errors now that
`bigint` is accepted as valid entry.
PR-URL: https://github.com/nodejs/node/pull/28173
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Yongsheng Zhang <zyszys98@gmail.com>
Currently the buffer benchmarks take significantly too long to
complete. This drastically reduces the overall runtime by removing
obsolete checked variations and reducing the iteration count.
It also improves the benchmarks by removing the deprecated
`new Buffer(size)` usage and some other small improvements.
PR-URL: https://github.com/nodejs/node/pull/26418
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Peter Marshall <petermarshall@chromium.org>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Lots of changes, but mostly just search/replace of
fixtures.readSync(...) to fixtures.readKey([new key]...)
Benchmarks modified to use fixtures.readKey(...):
benchmark/tls/throughput.js
benchmark/tls/tls-connect.js
benchmark/tls/secure-pair.js
Also be sure to review the change to L16 of
test/parallel/test-crypto-sign-verify.js
PR-URL: https://github.com/nodejs/node/pull/27962
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Lots of changes, but mostly just search/replace of
fixtures.readSync(...) to fixtures.readKey([new key]...)
Benchmarks modified to use fixtures.readKey(...):
benchmark/tls/throughput.js
benchmark/tls/tls-connect.js
benchmark/tls/secure-pair.js
Also be sure to review the change to L16 of
test/parallel/test-crypto-sign-verify.js
PR-URL: https://github.com/nodejs/node/pull/27962
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Fix some issues introduced/not fixed via
https://github.com/nodejs/node/pull/25094:
* Init hook is not emitted for a reused HTTPParser
* HTTPParser was still used as resource in init hook
* type used in init hook was always HTTPINCOMINGMESSAGE even for client
requests
* some tests have not been adapted to new resource names
With this change the async hooks init event is emitted during a call
to Initialize() as the type and resource object is available at this
time. As a result Initialize() must be called now which could be seen
as breaking change even HTTPParser is not part of documented API.
It was needed to put the ClientRequest instance into a wrapper object
instead passing it directly as async resource otherwise
test-domain-multi fails. I think this is because adding an EventEmitter
to a Domain adds a property 'domain' and the presence of this changes
the context propagation in domains.
Besides that tests still refering to resource HTTPParser have been
updated/improved.
Fixes: https://github.com/nodejs/node/issues/27467
Fixes: https://github.com/nodejs/node/issues/26961
Refs: https://github.com/nodejs/node/pull/25094
PR-URL: https://github.com/nodejs/node/pull/27477
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>