- Mar 02, 2019
-
-
Anna Henningsen authored
Where appropriate, use a helper that wraps around `ArrayBufferView::Buffer()` or `ArrayBufferView::CopyContents()` rather than `Buffer::Data()`, as that may help to avoid materializing the underlying `ArrayBuffer` when reading small typed arrays from C++. This allows keeping the performance benefits of the faster creation of heap-allocated small typed arrays in many cases. PR-URL: https://github.com/nodejs/node/pull/26301 Reviewed-By:
Matteo Collina <matteo.collina@gmail.com> Reviewed-By:
James M Snell <jasnell@gmail.com>
-
Anna Henningsen authored
This was added in 16f86d6c, based on the assumption that otherwise, the memory behind `ArrayBuffer` instances could be moved around on the heap while native code holds references to it. This does not match what V8 actually does (and also did at the time): - The option/build variable was about always only about TypedArrays, not ArrayBuffers. Calls like `new ArrayBuffer(4)` call into C++ regardless of the option value, but calls like `new Uint8Array(4)` would not call into C++ under V8 defaults. - When first accessing a heap-allocated TypedArray’s `ArrayBuffer`, whether that is through the JS `.buffer` getter or the C++ `ArrayBufferView::Buffer()` function, a copy of the contents is created using the ArrayBuffer allocator and stored as the (permanent, unmovable) backing store. As a consequence, the memory returned by `ArrayBuffer::GetContents()` is not moved around, because it is fixed once the `ArrayBuffer` object itself first comes into explicit existence in any way. Removing this build option significantly speeds up creation of typed arrays from JS: $ ./node benchmark/compare.js --new ./node --old ./node-master --runs 10 --filter buffer-creation.js buffers | Rscript benchmark/compare.R confidence improvement accuracy (*) (**) (***) buffers/buffer-creation.js n=1024 len=10 type='buffer()' *** 593.66 % ±28.64% ±41.10% ±60.36% buffers/buffer-creation.js n=1024 len=10 type='fast-alloc-fill' *** 675.42 % ±90.67% ±130.24% ±191.54% buffers/buffer-creation.js n=1024 len=10 type='fast-alloc' *** 663.55 % ±58.41% ±83.87% ±123.29% buffers/buffer-creation.js n=1024 len=10 type='fast-allocUnsafe' 3.10 % ±9.63% ±13.22% ±18.07% buffers/buffer-creation.js n=1024 len=10 type='slow-allocUnsafe' 4.67 % ±5.55% ±7.77% ±10.97% buffers/buffer-creation.js n=1024 len=10 type='slow' -2.48 % ±4.47% ±6.12% ±8.34% buffers/buffer-creation.js n=1024 len=1024 type='buffer()' -1.91 % ±4.71% ±6.45% ±8.79% buffers/buffer-creation.js n=1024 len=1024 type='fast-alloc-fill' -1.34 % ±7.53% ±10.33% ±14.10% buffers/buffer-creation.js n=1024 len=1024 type='fast-alloc' 0.52 % ±5.00% ±6.87% ±9.40% buffers/buffer-creation.js n=1024 len=1024 type='fast-allocUnsafe' 0.39 % ±5.65% ±7.78% ±10.67% buffers/buffer-creation.js n=1024 len=1024 type='slow-allocUnsafe' -0.13 % ±5.68% ±7.83% ±10.77% buffers/buffer-creation.js n=1024 len=1024 type='slow' -5.07 % ±7.15% ±9.80% ±13.35% buffers/buffer-creation.js n=1024 len=2048 type='buffer()' 0.57 % ±2.70% ±3.74% ±5.16% buffers/buffer-creation.js n=1024 len=2048 type='fast-alloc-fill' -1.60 % ±4.96% ±6.79% ±9.25% buffers/buffer-creation.js n=1024 len=2048 type='fast-alloc' 1.29 % ±3.79% ±5.20% ±7.09% buffers/buffer-creation.js n=1024 len=2048 type='fast-allocUnsafe' 2.73 % ±8.79% ±12.05% ±16.41% buffers/buffer-creation.js n=1024 len=2048 type='slow-allocUnsafe' -0.99 % ±6.27% ±8.65% ±11.91% buffers/buffer-creation.js n=1024 len=2048 type='slow' -5.98 % ±6.24% ±8.71% ±12.20% buffers/buffer-creation.js n=1024 len=4096 type='buffer()' -1.75 % ±3.48% ±4.78% ±6.56% buffers/buffer-creation.js n=1024 len=4096 type='fast-alloc-fill' -3.18 % ±3.97% ±5.45% ±7.45% buffers/buffer-creation.js n=1024 len=4096 type='fast-alloc' 2.05 % ±4.05% ±5.58% ±7.65% buffers/buffer-creation.js n=1024 len=4096 type='fast-allocUnsafe' 1.44 % ±5.51% ±7.63% ±10.57% buffers/buffer-creation.js n=1024 len=4096 type='slow-allocUnsafe' * -4.77 % ±4.30% ±5.90% ±8.06% buffers/buffer-creation.js n=1024 len=4096 type='slow' -3.31 % ±6.38% ±8.86% ±12.34% buffers/buffer-creation.js n=1024 len=8192 type='buffer()' 0.06 % ±2.70% ±3.77% ±5.31% buffers/buffer-creation.js n=1024 len=8192 type='fast-alloc-fill' -1.20 % ±3.30% ±4.53% ±6.17% buffers/buffer-creation.js n=1024 len=8192 type='fast-alloc' -1.46 % ±2.75% ±3.84% ±5.38% buffers/buffer-creation.js n=1024 len=8192 type='fast-allocUnsafe' 1.27 % ±4.69% ±6.49% ±8.98% buffers/buffer-creation.js n=1024 len=8192 type='slow-allocUnsafe' -1.68 % ±3.30% ±4.62% ±6.49% buffers/buffer-creation.js n=1024 len=8192 type='slow' -2.49 % ±3.24% ±4.44% ±6.07% (Re-running the outlier with 30 runs instead of 10:) buffers/buffer-creation.js n=1024 len=4096 type='slow-allocUnsafe' 2.06 % ±2.39% ±3.19% ±4.15% The performance gains effect are undone once native code accesses the underlying ArrayBuffer, but then again that a) does not happen for all TypedArrays, and b) it should also make sense to look into using `ArrayBufferView::CopyContents()` in some places, which is made specifically to avoid such a performance impact and allows us to use the benefits of heap-allocated typed arrays. Refs: https://github.com/nodejs/node/commit/16f86d6c578ff7aec708c7d736558a199d290e9c Refs: https://github.com/nodejs/node/pull/2893 Refs: https://github.com/nodejs/node/commit/74178a5682958d499896e0fa1af6bc0321ec1935#commitcomment-13250880 Refs: http://logs.libuv.org/node-dev/2015-09-15 PR-URL: https://github.com/nodejs/node/pull/26301 Reviewed-By:
-
Anna Henningsen authored
This was overlooked in c5832453. Refs: https://github.com/nodejs/node/pull/26137 PR-URL: https://github.com/nodejs/node/pull/26295 Reviewed-By:
Colin Ihrig <cjihrig@gmail.com> Reviewed-By:
Tobias Nießen <tniessen@tnie.de>
-
Anna Henningsen authored
It’s not obvious why this was a heap allocation in the first place, but it’s unneccessary. Most other `HandleWrap`s also store the libuv handle directly. PR-URL: https://github.com/nodejs/node/pull/26271 Reviewed-By:
Richard Lau <riclau@uk.ibm.com> Reviewed-By:
Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By:
Gireesh Punathil <gpunathi@in.ibm.com>
-
Anna Henningsen authored
PR-URL: https://github.com/nodejs/node/pull/26271 Reviewed-By:
-
Anna Henningsen authored
PR-URL: https://github.com/nodejs/node/pull/26243 Reviewed-By:
-
cjihrig authored
PR-URL: https://github.com/nodejs/node/pull/26368 Reviewed-By:
Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By:
Vse Mozhet Byt <vsemozhetbyt@gmail.com> Reviewed-By:
Luigi Pinca <luigipinca@gmail.com>
-
- Mar 01, 2019
-
-
Avi ד authored
Prevents moving left or right from placing the cursor in between code units comprising a code point. PR-URL: https://github.com/nodejs/node/pull/25723 Fixes: https://github.com/nodejs/node/issues/25693 Reviewed-By:
Anna Henningsen <anna@addaleax.net> Reviewed-By:
-
Ruben Bridgewater authored
This moves a condition inside of a for loop which can only be triggered at the very end of the for loop outside of the loop. That way the for loop itself is much simpler and easier to understand and the code itself is less indented which should increase the readability. It also refactors some `var` to `let` and `const`. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
Michaël Zasso <targos@protonmail.com>
-
Ruben Bridgewater authored
This moves the `if (len === 1)` case to the top of the function. That way it is possible to reduce the indentation level due to returning early in that case. On top of that the following was done: 1) For clarity refactored for loops which were meant to count up a variable into a while loop. 2) Used template strings instead of string concat. 3) Consolidating nested if statements. 4) Using tenary expressions if applicable when assigning variables to reduce the code overhead. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
Ruben Bridgewater authored
Either `end` is `-1` or `startPart` is not `0`. Therefore it's possible to move the conditions in a way that we eliminate a few code branches. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
Ruben Bridgewater authored
This refactoring makes sure some code branches will not be hit if they do not have to be reached. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
Ruben Bridgewater authored
1) Consolidate nested if statements if possible `if (foo) { if bar () { /* do stuff */ } }`) to reduce indentation depth. 2) Remove obsolete else cases to reduce indentation. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By: -
Ruben Bridgewater authored
1) Consolidate format to a single function. 2) Move some code that can only be reached in some code branches that was formerly executed in all cases. 3) Explicitly check for the string length of zero instead of converting the string to a boolean. 4) Consolidate nested if statements if possible e.g., if (foo) { if (bar) { /* do stuff */ } } to reduce indentation depth. 5) Simplify checks by removing extra length checks when comparing two strings. 6) Use object shorthand notation where possible. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By: -
Ruben Bridgewater authored
1) Refactor for loops to while loops that were only meant to count up a variable. 2) Refactor some `var` statements to `let` / `const`. 3) Simplify return conditions. 4) Use template strings where possible instead of concat. 5) Use ternary expressions for variable assignments instead of if / else. 6) Use the object shorthand notation for the function declarations. 7) Consolidate if else case where possible. 8) Remove double line breaks. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
Ruben Bridgewater authored
1) This uses some ternary expressions instead of if else to assign some variables. 2) Use template strings instead of concat. 3) Use the object shortand notation. 4) Some var to let / const. 5) Removed some double line breaks. 6) Less brackets around statements if not necessary. PR-URL: https://github.com/nodejs/node/pull/25278 Reviewed-By:
-
Ruben Bridgewater authored
The current caching logic broke by [0] because it used destructuring on the module arguments. Since the exported property is a primitive counting it up or down would not have any effect anymore in the module that required that property. The original implementation would cache all stat calls caused during bootstrap. Afterwards it would clear the cache and lazy require calls during runtime would create a new cascading cache for the then loaded modules and clear the cache again. This behavior is now restored. This is difficult to test without exposing a lot of information and therfore the existing tests have been removed (as they could not detect the issue). With the broken implementation it caused each module compilation to reset the cache and therefore minimizing the effect drastically. [0] https://github.com/nodejs/node/pull/19177 PR-URL: https://github.com/nodejs/node/pull/26266 Reviewed-By:
-
Ruben Bridgewater authored
This simplifies the shebang function significantly. Before, it was optimized for two characters input. Any module actually parsed should however have more characters than just the shebang. The performance stays the same as before. PR-URL: https://github.com/nodejs/node/pull/26266 Reviewed-By:
-
Alexander Sattelmaier authored
PR-URL: https://github.com/nodejs/node/pull/26163 Reviewed-By:
-
Alexander Sattelmaier authored
PR-URL: https://github.com/nodejs/node/pull/26163 Reviewed-By:
-
gengjiawen authored
PR-URL: https://github.com/nodejs/node/pull/26218 Reviewed-By:
-
MaleDong authored
Due to `maledong_private@qq.com` is useless because I cannot log in with the email address (GitHub doesn't support `qq` mail well), and I've successfully changed my email account to `maledong_github@outlook.com` instead. So I removed my old useless email address and keep the new one for the same account 'MaleDong', because there're two 'MaleDong' Accounts and they are both pointing to me. The final solution is that to add my own email account address into the '.mailmap' to let AUTHORS re-generated. PR-URL: https://github.com/nodejs/node/pull/26146 Reviewed-By:
-
Anna Henningsen authored
In the presence of Workers, it is not safe to assume that `StreamPipe::Unpipe()` has been called at the time when the object is destroyed. Instead, clean up when the destructor is called. PR-URL: https://github.com/nodejs/node/pull/26256 Reviewed-By:
Joyee Cheung <joyeec9h3@gmail.com>
-
Anna Henningsen authored
Do not access handles that have already begun to be closed or are closed. PR-URL: https://github.com/nodejs/node/pull/26256 Reviewed-By:
-
Gireesh Punathil authored
The current mechanism of uses two async handles, one owned by the creator of the worker thread to terminate a running worker, and another one employed by the worker to interrupt its creator on its natural termination. The force termination piggybacks on the message- passing mechanism to inform the worker to quiesce. Also there are few flags that represent the other thread's state / request state because certain code path is shared by multiple control flows, and there are certain code path where the async handles may not have come to life. Refactor into an AsyncRequest abstraction that exposes routines to install a handle as well as to save a state. PR-URL: https://github.com/nodejs/node/pull/26099 Refs: https://github.com/nodejs/node/pull/21283 Reviewed-By:
-
Ruben Bridgewater authored
This is only a reference to the instance and should not be used. PR-URL: https://github.com/nodejs/node/pull/26260 Reviewed-By:
Jeremiah Senkpiel <fishrock123@rocketmail.com> Reviewed-By:
Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By:
-
Ruben Bridgewater authored
When using `util.inspect()` with `compact` mode set to a number, all array entries exceeding 6 are going to be grouped together into logical parts. PR-URL: https://github.com/nodejs/node/pull/26269 Reviewed-By:
-
Ruben Bridgewater authored
This overloads the `compact` option from `util.inspect()`. If it's set to a number, it is going to align all most inner entries on the same lign if they adhere to the following: * The entries do not exceed the `breakLength` options value. * The entry is one of the local most inner levels up the the one provided in `compact`. PR-URL: https://github.com/nodejs/node/pull/26269 Reviewed-By:
-
Michael Wei authored
PR-URL: https://github.com/nodejs/node/pull/26300 Reviewed-By:
Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By:
-
Jarrod Connolly authored
Implements `napi_create_date()` as well as `napi_is_date()` to allow working with JavaScript Date objects. PR-URL: https://github.com/nodejs/node/pull/25917 Reviewed-By:
-
Sam Roberts authored
The cast is needed to build against OpenSSL 1.0.2, which master, 11.x, and 10.x no longer support. PR-URL: https://github.com/nodejs/node/pull/26305 Reviewed-By:
Sakthipriyan Vairamani <thechargingvolcano@gmail.com> Reviewed-By:
-
Mukul Khanna authored
PR-URL: https://github.com/nodejs/node/pull/26308 Reviewed-By:
-
Ruben Bridgewater authored
This prevents any proxy traps from being called while inspecting proxy objects. That guarantees a side-effect free way of inspecting proxies. PR-URL: https://github.com/nodejs/node/pull/26241 Fixes: https://github.com/nodejs/node/issues/10731 Fixes: https://github.com/nodejs/node/issues/26231 Refs: https://github.com/nodejs/node/issues/25212 Refs: https://github.com/nodejs/node/issues/24765 Reviewed-By:
-
Ruben Bridgewater authored
This updates a lot of comments. PR-URL: https://github.com/nodejs/node/pull/26223 Reviewed-By:
Rich Trott <rtrott@gmail.com> Reviewed-By:
-
Ruben Bridgewater authored
This prevents leaking of the internal `inspect()` properties when using a custom inspect function. It also aligns the indentation to the way it was in v8.0.0 since that changed unintentionally. All strings returned by the custom inspect function will now be indented appropriately to the current depth. PR-URL: https://github.com/nodejs/node/pull/24971 Refs: https://github.com/nodejs/node/issues/24765 Reviewed-By:
Gus Caplan <me@gus.host> Reviewed-By:
-
Ruben Bridgewater authored
This makes sure the internal `stylize` function is not used to render anything and instead just uses the regular inspect function in case of reaching the maximum depth level. PR-URL: https://github.com/nodejs/node/pull/24971 Refs: https://github.com/nodejs/node/issues/24765 Reviewed-By:
-
Ruben Bridgewater authored
It is possible to distinguish the entries iterator from others. Expose that information to the users as well and improve the Symbol.toStringTag handling by adding a special tag instead of replacing the existent information. PR-URL: https://github.com/nodejs/node/pull/26222 Reviewed-By:
-
Ruben Bridgewater authored
The cpp linter is very noisy at the moment. So use the --quiet flag by default instead of being verbose in this case. PR-URL: https://github.com/nodejs/node/pull/26252 Reviewed-By:
Daniel Bevenius <daniel.bevenius@gmail.com> Reviewed-By:
-
Richard Lau authored
Fixes `maybe-uninitialized` build warning in `src/node_report.cc`. PR-URL: https://github.com/nodejs/node/pull/26265 Reviewed-By:
-
- Feb 28, 2019
-
-
Matteo Collina authored
Fixes: https://github.com/nodejs/node/issues/26097 PR-URL: https://github.com/nodejs/node/pull/26135 Reviewed-By:
-
