buffer: improve creation performance #6893

RReverser · 2016-05-20T10:01:59Z

Checklist

tests and code linting passes
the commit message follows commit guidelines

Affected core subsystem(s)

buffer

Description of change

Improves performance of allocating unsafe buffers, creating buffers from
an existing ArrayBuffer and creating .slice(...) from existing Buffer by
avoiding deoptimizing change of prototype after Uint8Array allocation
in favor of ES6 native subclassing.

This is done through an internal ES6 class that extends Uint8Array and
is used for allocations, but the regular Buffer function is exposed, so
calling Buffer(...) with or without new continues to work as usual
and prototype chains are also preserved.

Performance wins for .slice are +120% (2.2x), and, consequently, for
unsafe allocations up to +95% (1.9x) for small buffers, and for safe
allocations (zero-filled) up to +30% (1.3x).

RReverser · 2016-05-20T10:05:43Z

cc @trevnorris as per request

targos · 2016-05-20T10:12:26Z

CI: https://ci.nodejs.org/job/node-test-pull-request/2710/

RReverser · 2016-05-20T10:48:40Z

CI finished, I see only two failures in Windows build configs which are network timeouts. I guess unrelated?

Fishrock123 · 2016-05-20T14:05:37Z

Hasn't Trevor already changed this between JS and C++ like 3 times? 😂

RReverser · 2016-05-20T14:11:29Z

@Fishrock123 Well, it's mostly in JS, but the inheritance from Uint8Array was done inefficiently. I just additionally removed CreateFromArrayBuffer in C++ as it's not needed when you have native subclass of Uint8Array which can be already instantiated with an ArrayBuffer as an argument (and do that faster).

TL;DR: the biggest win here is unrelated to the C++ change, but rather to the ES6 native subclassing.

jasnell · 2016-05-20T14:23:05Z

@nodejs/buffer

eljefedelrodeodeljefe · 2016-05-21T21:56:59Z

I like the changes very much. Also makes it more readable...

I'll test around .slice since I conducted some experiments and found out that v8 is already really fast there. I am curious whether there is an regression now.

RReverser · 2016-05-22T12:44:29Z

v8 is already really fast there

Well, now Buffer.slice is very close to Uint8Array.subarray (I was comparing against it in my local benchmarks as a "theoretical maximum" which obviously can't be achieved in a wrapper, but can be very close (and it is now)).

Please do let me know if I missed something / need to change before this can be merged.

ChALkeR · 2016-05-22T12:52:32Z

lib/buffer.js

@@ -213,7 +214,7 @@ function allocate(size) {
    // Even though this is checked above, the conditional is a safety net and


Side note: this comment is irrelevant now, probably since dd67608, I overlooked it.
/cc @trevnorris

Looks like it can be removed.

Looks like it has returned after a rebase =).
It's not critical, though, that could be removed later.

RReverser · 2016-05-22T18:55:11Z

Not directly related, but now that I'm trying to submit changes from my Windows machine (previous one was from Mac), I've found one error: .eslintrc reports every line as invalid due to linebreak-style: [2, "unix"] in .eslintrc, while Git by default matches OS native endlines and checks out with CRLF (unless .gitattributes specifies custom eol for all text files, and it doesn't in this repo).

What would be the best fix for this - a PR that removes .eslintrc rule against that or a PR that adds * text=auto eol=lf or [another option]?

addaleax · 2016-05-22T18:56:58Z

I think that discussion would best be taken to #6912 :)

RReverser · 2016-05-22T18:59:19Z

Oh cool, thanks! That's a new issue I haven't noticed yet :)

RReverser · 2016-05-22T19:08:11Z

Btw, can someone please explain what

function SlowBuffer(length) {
  if (+length != length)
    length = 0;

is for / supposed to do? Just tried to wrap my head around it, and wasn't sure whether the additional semantics on top of simple typeof length !== 'number' were intended or accidental.

addaleax · 2016-05-22T19:27:04Z

There was some discussion on that in #2635… though I can’t seem to find the advantage of using +length != length, either. It behaves differently for inputs like false or '42', and probably not even in a wanted way.

addaleax · 2016-05-22T19:28:25Z

Note that it only exists as part of a deprecated API anyway.

RReverser · 2016-05-22T19:32:44Z

It behaves differently for inputs like false or '42', and probably not even in a wanted way.

Exactly my thoughts.

Note that it only exists as part of a deprecated API anyway.

That's true, just looks pretty weird when trying to read / understand the code.

addaleax · 2016-05-22T19:50:19Z

test/parallel/test-buffer-alloc.js

+
+// Regression test
+assert.doesNotThrow(() => {
+  new Buffer(new ArrayBuffer());


This should preferably use Buffer.from instead of new Buffer

addaleax · 2016-05-22T20:02:41Z

I’d maybe separate the <= to < change, along with its regresseion test, out into its own commit that can be landed separately too.

LGTM either way.

RReverser · 2016-05-22T20:05:46Z

@addaleax Isn't 9d480d9 exactly that? (well, it also removes a comment but that's a non-functional change anyway).

addaleax · 2016-05-22T20:17:29Z

@RReverser Kinda… you don’t have to move that if you don’t want to, but keep in mind that the commit history ideally still makes sense for someone looking at it in a few years, without having the context of this PR in mind. Happens more often than you think. :)

Also, it would be cool if you could re-format the commit message for that commit so that it adheres to the guidelines (i.e. it starts with buffer:, has an all-lowercase subject line, and is under < 72 columns)

trevnorris · 2016-06-03T22:41:50Z

Hm. If this PR addresses the comment removal, leave it in its own commit. Yes it's minor, but if this needs to be reverted for some unforeseen reason don't want the comment coming back in.

As far as the regression, I vote we leave that to its own PR (since it'll require it's own regression test, etc.).

addaleax · 2016-06-03T22:47:27Z

@trevnorris Want to go ahead and land this then?

ChALkeR · 2016-06-03T23:09:19Z

lib/buffer.js

-  if (size <= 0)
-    return createBuffer(size);
-  if (fill !== undefined) {
+  if (size > 0 && fill !== undefined) {


Does a separate check for 0 make sense here, i.e. size > 0 && fill !== undefined && fill !== 0?

Buffer.alloc(size, 0) is equivalent to Buffer.alloc(size), so just new FastBuffer(size) should work faster in that case.

Hm, I think that would require benchmarking – createUnsafeBuffer() returns a slice from the pool, so I’d actually expect that to be faster than an extra typed array allocation.

@addaleax It's not just createUnsafeBuffer, it's createUnsafeBuffer + fill(0).
I believe that has been discussed before, and allocation was proven to be faster — that's why simple Buffer.alloc(size) does not use the pool.

@ChALkeR I know there’s the extra fill() in there. But if you say it’s faster, I believe that :)

@addaleax Btw, nothing in this function uses slices from the pool. Perhaps it should?
Both new FastBuffer and createUnsafeBuffer just directly allocate a new instance.

Oh, right. Maybe, but I’d leave that open for another PR, too, especially as it would introduce the subtle change that the return values of Buffer.alloc() would share their buffer property.

i'm down for that change. The kernel can probably optimize calls to calloc() a hair better. Though not going to consider it a blocking change.

ChALkeR · 2016-06-03T23:22:41Z

LGTM

trevnorris · 2016-06-03T23:33:07Z

@addaleax Going ahead w/ these sounds good to me.

ChALkeR · 2016-06-03T23:33:29Z

Curious: would

Buffer.alloc = function(size, fill, encoding) {
  assertSize(size);
  if (size > 0 && fill !== undefined && fill !== 0) {
    if (typeof encoding !== 'string')
      encoding = undefined;
    return allocate(size).fill(fill, encoding);
  }
  return new FastBuffer(size);
};

be faster for short buffers filled with some non-zero argument?

There are two changes here: && fill !== 0 (for Buffer.alloc(size, 0) opt), and createUnsafeBuffer to allocate change to use the pool for short buffers.

ChALkeR · 2016-06-03T23:35:58Z

On a second thought, we can do that in a separate PR, those are independent changes.
This PR LGTM.

addaleax · 2016-06-06T04:12:55Z

I’m going to land this later today if nobody beats me to it.

RReverser · 2016-06-06T09:57:14Z

On a second thought, we can do that in a separate PR, those are independent changes.
This PR LGTM.

Yes, thought about similar further optimizations, but they would be rather backward-incompatible and cases where they give any win are more rare, so decided not to change.

Improves performance of allocating unsafe buffers, creating buffers from an existing ArrayBuffer and creating .slice(...) from existing Buffer by avoiding deoptimizing change of prototype after Uint8Array allocation in favor of ES6 native subclassing. This is done through an internal ES6 class that extends Uint8Array and is used for allocations, but the regular Buffer function is exposed, so calling Buffer(...) with or without `new` continues to work as usual and prototype chains are also preserved. Performance wins for .slice are +120% (2.2x), and, consequently, for unsafe allocations up to +95% (1.9x) for small buffers, and for safe allocations (zero-filled) up to +30% (1.3x). PR-URL: #6893 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Сковорода Никита Андреевич <[email protected]>

addaleax · 2016-06-06T11:31:23Z

Landed in 5292a13. Thanks for the contribution and for your patience with us!

RReverser · 2016-06-06T11:42:52Z

@addaleax Thank you! That was quite a trip, but totally fine as for the first PR to the project :)

addaleax · 2016-06-06T11:55:50Z

That was quite a trip

No arguing about that. 😄 If you like, you can also do PRs for some of the issues that popped up as side notes in the discussion here. If not, you don’t have to, of course.

That one obsolete comment mentioned here: buffer: improve creation performance #6893 (comment)
The regression for creating buffers from zero-length ArrayBuffers mentioned here: buffer: improve creation performance #6893 (comment)
The fill === 0 check/performance improvement mentioned here: buffer: improve creation performance #6893 (comment)

… if I’ve managed to get everything right. ;)

ChALkeR · 2016-06-06T11:58:53Z

@addaleax Also .alloc(size, fill) should probably use the pool since it fills manually either way — #6893 (comment).

RReverser · 2016-06-06T12:02:35Z

@addaleax

The regression for creating buffers from zero-length ArrayBuffers mentioned here: #6893 (comment)

Found that commit: 7454298

Should I just submit it as a new PR?

addaleax · 2016-06-06T12:03:54Z

@RReverser sounds good, yup :)

trevnorris · 2016-06-07T20:25:20Z

@ChALkeR It was deliberate to not have Buffer.alloc() use the pool, since it was introduced to force the user to safety, and allocating from the pool allows others to read your memory. For example:

var b;
while ((b = Buffer.allocUnsafe(1)).byteOffset > 0);
Buffer.from(b.buffer).fill(0);
setTimeout(() => {
  // See what else has been written to the buffer since
  console.log(b);
}, 3000);

Can collect more information by messing with Buffer.poolSize. The argument is that allowing those allocations to come from the pool undermines the secure aspect they're focused on.

ChALkeR · 2016-06-07T20:35:39Z

@trevnorris Ah, understood. I personally don't see how that is a problem, because .buffer properties are accessible only locally (i.e. not saved to the db, not transfered over network, etc), and we don't (and can't) gurantee any safety in presence of local malicious code.

But ok, let's keep it that way if there are concerns about that. Perhaps that should be documented as a small one-line comment in the source code?

trevnorris · 2016-06-07T20:51:05Z

@ChALkeR That decision was simply my call when it was first implemented to make sure the PR would avoid additional scrutiny. If everyone's alright with using the pool then I won't stand in the way.

ChALkeR · 2016-06-08T14:26:47Z

@trevnorris On a second though, I think that you are correct here and that we should keep that as it is now. There could be various code errors on user side which could potentially cause issues if the code somehow uses the .buffer property.

Also, the current behaviour is documented, and changing that would be a semver-major.

So let's not change that =).

evanlucas · 2016-06-16T02:31:33Z

This depends on #7082 and #7093, both of which have been marked dont-land-on-v6.x. @RReverser interested in opening a backport PR against the v6.x branch?

RReverser · 2016-06-16T08:23:29Z

#7176 (comment) same question here

Improves performance of allocating unsafe buffers, creating buffers from an existing ArrayBuffer and creating .slice(...) from existing Buffer by avoiding deoptimizing change of prototype after Uint8Array allocation in favor of ES6 native subclassing. This is done through an internal ES6 class that extends Uint8Array and is used for allocations, but the regular Buffer function is exposed, so calling Buffer(...) with or without `new` continues to work as usual and prototype chains are also preserved. Performance wins for .slice are +120% (2.2x), and, consequently, for unsafe allocations up to +95% (1.9x) for small buffers, and for safe allocations (zero-filled) up to +30% (1.3x). PR-URL: #7349 Ref: #6893 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Сковорода Никита Андреевич <[email protected]> Reviewed-By: Trevor Norris <[email protected]>

nodejs-github-bot added buffer Issues and PRs related to the buffer subsystem. c++ Issues and PRs that require attention from people who are familiar with C++. labels May 20, 2016

ChALkeR reviewed May 22, 2016
View reviewed changes

addaleax reviewed May 22, 2016
View reviewed changes

RReverser mentioned this pull request May 22, 2016

buffer: Fix dataview-set benchmark. #6922

Closed

3 tasks

ChALkeR reviewed Jun 3, 2016
View reviewed changes

addaleax closed this Jun 6, 2016

RReverser mentioned this pull request Jun 6, 2016

buffer: fix creating from zero-length ArrayBuffer #7176

Closed

3 tasks

rvagg mentioned this pull request Jun 8, 2016

governance: add new collaborators XIV #7197

Closed

5 tasks

evanlucas added the dont-land-on-v6.x label Jun 16, 2016

RReverser mentioned this pull request Jun 21, 2016

Backport 6893 for v6.x (buffer: improve creation performance) #7349

Closed

2 tasks

gibfahn mentioned this pull request Jun 15, 2017

Auditing for 6.11.1 nodejs/Release#230

Closed

3 tasks

		@@ -213,7 +214,7 @@ function allocate(size) {
		// Even though this is checked above, the conditional is a safety net and

buffer: improve creation performance #6893

buffer: improve creation performance #6893

Conversation

RReverser commented May 20, 2016

Checklist

Affected core subsystem(s)

Description of change

RReverser commented May 20, 2016

targos commented May 20, 2016

RReverser commented May 20, 2016

Fishrock123 commented May 20, 2016

RReverser commented May 20, 2016 • edited Loading

jasnell commented May 20, 2016

eljefedelrodeodeljefe commented May 21, 2016

RReverser commented May 22, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

RReverser commented May 22, 2016

addaleax commented May 22, 2016

RReverser commented May 22, 2016

RReverser commented May 22, 2016

addaleax commented May 22, 2016

addaleax commented May 22, 2016

RReverser commented May 22, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

addaleax commented May 22, 2016

RReverser commented May 22, 2016

addaleax commented May 22, 2016

trevnorris commented Jun 3, 2016

addaleax commented Jun 3, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChALkeR Jun 3, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChALkeR Jun 3, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ChALkeR commented Jun 3, 2016

trevnorris commented Jun 3, 2016

ChALkeR commented Jun 3, 2016

ChALkeR commented Jun 3, 2016 • edited Loading

addaleax commented Jun 6, 2016

RReverser commented Jun 6, 2016

addaleax commented Jun 6, 2016

RReverser commented Jun 6, 2016

addaleax commented Jun 6, 2016

ChALkeR commented Jun 6, 2016

RReverser commented Jun 6, 2016

addaleax commented Jun 6, 2016

trevnorris commented Jun 7, 2016

ChALkeR commented Jun 7, 2016 • edited Loading

trevnorris commented Jun 7, 2016

ChALkeR commented Jun 8, 2016

evanlucas commented Jun 16, 2016

RReverser commented Jun 16, 2016

RReverser commented May 20, 2016 •

edited

Loading

ChALkeR Jun 3, 2016 •

edited

Loading

ChALkeR Jun 3, 2016 •

edited

Loading

ChALkeR commented Jun 3, 2016 •

edited

Loading

ChALkeR commented Jun 7, 2016 •

edited

Loading