Call with V8 team

[indutny]

Hello everyone!

I think we should coordinate and schedule a joint call between Node.js CTC and V8 team to discuss following topic:

• GYP vs GN, and how both projects could move forward on this
• General performance feedback

cc @nodejs/ctc @bmeurer

[sam-github]

Object.assign()!

[hashseed]

cc @ofrobots

[bmeurer]

Would be really interested to hear feedback for Object.assign(). We spend some time optimizing that last year, but maybe there's more we can do!

[sam-github]

@cjihrig @Trott Why do we think its slower than util._extend(), and to be avoided?

[cjihrig]

I think every time someone benchmarked the two, util._extend() came out faster. That's not to say that Object.assign() might have improved since last we checked. Here are some related PRs:

• util: deprecate util._extend node#4593
• Remove deprecated function node#6977
• lib: replace util._extend with object.assign node#7208
• util: runtime deprecation for util._extend() node#10849

People have reported seeing util._extend() win by up to 50%, although, again, that might not currently be the case. FWIW, I'm in favor of using Object.assign() if the performance has improved enough.

EDIT: A benchmark was provided in nodejs/node#7255.

[Trott]

Here are two different benchmarks with conflicting results. So which one is faster may depend on your use case.

Here's the one showing `util._extend()` being faster.

Here is a slightly modified version of a benchmark originally written by @jasnell.

Code

'use strict';

const common = require('../common');
const util = require('util');

const bench = common.createBenchmark(main, {
  method: ['Object.assign()', 'util._extend()'],
  size: [5, 10, 15, 30],
  n: [1e5]
});

function makeObject(size) {
  var m = {};
  for (var n = 0; n < size; n++)
    m[`key${n}`] = n;
  return m;
}

function useObjectAssign(n, obj) {
  bench.start();
  for (var i = 0; i < n; i++) {
    Object.assign({}, obj);
  }
  bench.end(n);
}

function useUtilExtend(n, obj) {
  bench.start();
  for (var i = 0; i < n; i++) {
    util._extend({}, obj);
  }
  bench.end(n);
}

function main(conf) {
  const n = +conf.n;
  const obj = makeObject(+conf.size);

  switch (conf.method) {
    case 'Object.assign()':
      useObjectAssign(n, obj);
      break;
    case 'util._extend()':
      useUtilExtend(n, obj);
      break;
    default:
      throw new Error('Unexpected method');
  }
}

Results

es/more-different-object-assign.js n=100000 size=5 method="Object.assign()": 1,250,221.8987592561
es/more-different-object-assign.js n=100000 size=10 method="Object.assign()": 631,233.9839762895
es/more-different-object-assign.js n=100000 size=15 method="Object.assign()": 370,360.6970976447
es/more-different-object-assign.js n=100000 size=30 method="Object.assign()": 91,588.78644709584
es/more-different-object-assign.js n=100000 size=5 method="util._extend()": 4,757,977.84419069
es/more-different-object-assign.js n=100000 size=10 method="util._extend()": 2,845,257.808810056
es/more-different-object-assign.js n=100000 size=15 method="util._extend()": 2,240,614.63106566
es/more-different-object-assign.js n=100000 size=30 method="util._extend()": 253,510.71525401654

Here's the one showing `Object.assign()` being faster.

This is a modified version of a benchmark originally written by @suryagh.

Code

'use strict';

const common = require('../common.js');
const util = require('util');

const bench = common.createBenchmark(main, {
  n: [1, 10, 100, 1000],
  method: ['_extend', 'assign']
});

const methods = {
  '_extend': util._extend,
  'assign': Object.assign
}

function main(conf) {
  const n = +conf.n;
  const method = methods[conf.method];

  const target = {};

  bench.start()
  for (var i = 0; i < n; i++) {
    method(target, {i: i});
  }
  bench.end(n)
}

Results

es/object-assign.js method="_extend" n=1: 11,816.559726801139
es/object-assign.js method="assign" n=1: 13,891.590031394993
es/object-assign.js method="_extend" n=10: 73,593.80634525798
es/object-assign.js method="assign" n=10: 74,392.03112562583
es/object-assign.js method="_extend" n=100: 646,663.2177961718
es/object-assign.js method="assign" n=100: 716,707.1606212418
es/object-assign.js method="_extend" n=1000: 2,613,279.116502596
es/object-assign.js method="assign" n=1000: 3,053,313.914256839

[andrasq]

they're different tests -- one copies an object with 10,15,30 fields, the other
transfers 10,100,1000 properties to an existing object one property at a time.

[Trott]

they're different tests -- one copies an object with 10,15,30 fields, the other
transfers 10,100,1000 properties to an existing object one property at a time.

Yes, I probably shouldn't have said "conflicting". I didn't mean "contradictory" or "paradoxical" or anything like that. I just meant what results you get depend on what you're testing. Although I guess I should also add that the one showing util._extend() faster is probably the more realistic/typical use.

[bmeurer]

cc @verwaest who did the Object.assign() improvements.

[jasnell]

I was just playing with this a bit earlier this week. util._extend() consistently outperformed Object.assign() by about 200-300%. The different was significant. I included a new benchmark test in nodejs/node#10849

[andrasq]

I can confirm the above, _extend is 2-5x faster. The exceptions are the
empty object {} (assign 2x faster) and objects with a single property (30% faster),
and object whose property names are numeric strings. The last two are why
the test that copies properties singly favors assign.

Also, there is an order of magnitude speed difference between copying objects
whose properties are indexed by numeric strings "123" vs words "a123"
(indexing by words up to 12x faster), but this has to be due to v8 internals.
The speed to copy gradually slows for large numeric values up to 4 billion (2^32);
above 2^32 numeric strings run as fast as words. This quirk can bias benchmarks.

E.g., extend/assign relative rates for an object with 10 properties:
property names numeric strings '0' .. '9':
extend: 1.00x
assign: 1.25x
property names '1230' .. '1239':
extend: 1.18x
assign: 0.90x
property names '4000000000' ... '4000000009':
extend: 0.45x
assign: 0.80x
property names words 'a0' .. 'a9':
extend: 12x
assign: 1.9x
(timed with node-v7.4.0)

(Unrelated, but surprisingly _extend reverses the order of the properties;
_extend({}, {a:1, b:2}) yields the unexpected {b:2, a:1}.)

[verwaest-zz]

There is definitely still room for improvement in Object.assign. We'll should to look into it again sometime soon. OTOH you have to be careful with microbenchmarks for hand rolled versions because they may look fast in isolation but won't always give good perf when used in an application. They will quickly really on a shared cache that only starts conflicting when there are other users as well. Object.assign doesn't have that issue.

…

On Thu, Jan 19, 2017, 20:03 Andras ***@***.***> wrote: I can confirm the above, _extend is 2-5x faster. The exceptions are the empty object {} (assign 2x faster) and objects with a single property (30% faster), and object whose property names are numeric strings. The last two are why the test that copies properties singly favors assign. Also, there is an order of magnitude speed difference between copying objects whose properties are indexed by numeric strings "123" vs words "a123" (indexing by words up to 12x faster), but this has to be due to v8 internals. The speed to copy gradually slows for large numeric values up to 4 billion (2^32); above 2^32 numeric strings run as fast as words. This quirk can bias benchmarks. E.g., extend/assign relative rates for an object with 10 properties: property names numeric strings '0' .. '9': extend: 1.00x assign: 1.25x property names '1230' .. '1239': extend: 1.18x assign: 0.90x property names '4000000000' ... '4000000009': extend: 0.45x assign: 0.80x property names words 'a0' .. 'a9': extend: 12x assign: 1.9x (timed with node-v7.4.0) (Unrelated, but surprisingly _extend reverses the order of the properties; _extend({}, {a:1, b:2}) yields the unexpected {b:2, a:1}.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#62 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASgHlve2POgC9NwuTk2LmGBd5lc5p-gks5rT7OFgaJpZM4Ll2Fv> .

[ofrobots]

I think the discussion on Object.assign is potentially interesting, but it seems that it has hijacked the original intent of this issue. I do think it would good to have a call w/ the V8 team. Any interest from the CTC on that?

As for logistics, since most of the V8 team is Central European time-zone, perhaps the standard CTC afternoon Europe / morning Pacific time slot could work, but on a different day?

[Trott]

I think the discussion on Object.assign is potentially interesting, but it seems that it has hijacked the original intent of this issue. I do think it would good to have a call w/ the V8 team. Any interest from the CTC on that?

o/

As for logistics, since most of the V8 team is Central European time-zone, perhaps the standard CTC afternoon Europe / morning Pacific time slot could work, but on a different day?

That would be the 16:00 UTC time which (depending on daylight savings status) is 8am PST, 9am PDT, 5pm CET, and 6pm CEST.

(For anyone who cares: Confusingly, the "S" in PST means "standard" so that's the time in winter as compared to "daylight savings" time in summer. The "S" in CEST is for "summer" so it's basically the opposite of the "S" in PST.)