Degraded performance of ia32 builds on x64 Windows and undocumented build parameter

[vsemozhetbyt]

• Version: master / vee-eight-lkgr (8.0.0-pre)
• Platform: Windows 7 x64
• Subsystem: build, child_process

I've noticed a substantial difference between downloaded Node.js binaries and binaries built locally by myself.

For example, master and vee-eight-lkgr built today vs node.8.0.0-nightly20170221:

1. Are ~3-4 MB less.
2. Have degraded performance for child_process.exec() and child_process.execSync()

Test script and data:

'use strict';

console.log(`\n// v8 ${process.versions.v8} (Node.js ${process.versions.node})\n`);

const exec     = require('child_process').exec;
const execSync = require('child_process').execSync;

console.time('exec');
for (let i = 0; i < 1e2; i++) exec('echo');
console.timeEnd('exec');

console.time('execSync');
for (let i = 0; i < 1e2; i++) execSync('echo');
console.timeEnd('execSync');

// v8 4.5.103.45 (Node.js 4.8.0)

exec: 362ms
execSync: 717ms

// v8 5.1.281.93 (Node.js 6.10.0)

exec: 317.696ms
execSync: 720.335ms

// v8 5.5.372.40 (Node.js 7.6.0)

exec: 329.204ms
execSync: 780.849ms

// v8 5.5.372.40 (Node.js 8.0.0-nightly201702211162e284ca)

exec: 355.399ms
execSync: 754.043ms

// v8 5.5.372.40 (Node.js 8.0.0-pre)

exec: 1708.721ms
execSync: 2392.159ms

// v8 5.8.202 (Node.js 8.0.0-pre)

exec: 1693.617ms
execSync: 2367.062ms

The first 4 binaries are downloaded from the site, the last two are built locally from downloaded GitHub source zip according to BUILDING.md (with chcp 1252 before building to be on the safe side). All tests are OK.

What am I doing possibly wrong?

[seishun]

1. How did you build it?
2. What's your Visual Studio version?

[vsemozhetbyt]

@seishun
1.a. Download and unpack source zip.
1.b. chcp 1252 and .\vcbuild test in the cmd.exe.

2. I use Visual C++ 2015 Build Tools v14.0.25420.1

[vsemozhetbyt]

Profiler log for this test from Node.js 8.0.0-nightly201702211162e284ca (downloaded) (click me):

Statistical profiling result from v8.log, (78 ticks, 9 unaccounted, 0 excluded).

 [Shared libraries]:
   ticks  total  nonlib   name

 [JavaScript]:
   ticks  total  nonlib   name
     41   52.6%   52.6%  Handler: writeBuffer
      4    5.1%    5.1%  Stub: RecordWriteStub {2}
      4    5.1%    5.1%  Stub: GrowArrayElementsStub
      3    3.8%    3.8%  Stub: RecordWriteStub {1}
      3    3.8%    3.8%  Handler: error
      2    2.6%    2.6%  Stub: RecordWriteStub {3}
      1    1.3%    1.3%  Stub: ToBooleanICStub(Undefined,Null)
      1    1.3%    1.3%  Stub: RecordWriteStub {4}
      1    1.3%    1.3%  Stub: RecordWriteStub
      1    1.3%    1.3%  Stub: LoadGlobalICTrampolineStub
      1    1.3%    1.3%  Stub: LoadFieldStub
      1    1.3%    1.3%  Stub: FastCloneShallowObjectStub
      1    1.3%    1.3%  Stub: CallICStub(args(5), NULL_OR_UNDEFINED, 
      1    1.3%    1.3%  Stub: BinaryOpICStub
      1    1.3%    1.3%  Handler: toString {NaN}
      1    1.3%    1.3%  Handler: server
      1    1.3%    1.3%  Handler: fs
      1    1.3%    1.3%  Handler: _maxListeners

 [C++]:
   ticks  total  nonlib   name

 [Summary]:
   ticks  total  nonlib   name
     69   88.5%   88.5%  JavaScript
      0    0.0%    0.0%  C++
      1    1.3%    1.3%  GC
      0    0.0%          Shared libraries
      9   11.5%          Unaccounted

 [C++ entry points]:
   ticks    cpp   total   name

 [Bottom up (heavy) profile]:
  Note: percentage shows a share of a particular caller in the total
  amount of its parent calls.
  Callers occupying less than 2.0% are not shown.

   ticks parent  name
     41   52.6%  Handler: writeBuffer
     40   97.6%    f:\BAK\prg\prg\nodes\node.8.0.0-nightly20170221.exe

      9   11.5%  UNKNOWN

      4    5.1%  Stub: RecordWriteStub {2}
      4  100.0%    f:\BAK\prg\prg\nodes\node.8.0.0-nightly20170221.exe

      4    5.1%  Stub: GrowArrayElementsStub
      4  100.0%    f:\BAK\prg\prg\nodes\node.8.0.0-nightly20170221.exe

      3    3.8%  Stub: RecordWriteStub {1}
      3  100.0%    f:\BAK\prg\prg\nodes\node.8.0.0-nightly20170221.exe

      3    3.8%  Handler: error
      3  100.0%    f:\BAK\prg\prg\nodes\node.8.0.0-nightly20170221.exe

      2    2.6%  Stub: RecordWriteStub {3}
      2  100.0%    f:\BAK\prg\prg\nodes\node.8.0.0-nightly20170221.exe

Profiler log for this test from node master (local build) (click me):

Statistical profiling result from v8.log, (199 ticks, 192 unaccounted, 0 excluded).

 [Shared libraries]:
   ticks  total  nonlib   name

 [JavaScript]:
   ticks  total  nonlib   name
      6    3.0%    3.0%  Builtin: StringPrototypeNormalize
      1    0.5%    0.5%  Stub: CompareICStub

 [C++]:
   ticks  total  nonlib   name

 [Summary]:
   ticks  total  nonlib   name
      7    3.5%    3.5%  JavaScript
      0    0.0%    0.0%  C++
      0    0.0%    0.0%  GC
      0    0.0%          Shared libraries
    192   96.5%          Unaccounted

 [C++ entry points]:
   ticks    cpp   total   name

 [Bottom up (heavy) profile]:
  Note: percentage shows a share of a particular caller in the total
  amount of its parent calls.
  Callers occupying less than 2.0% are not shown.

   ticks parent  name
    192   96.5%  UNKNOWN
    190   99.0%    f:\BAK\prg\prg\nodes\node.master.exe

      6    3.0%  Builtin: StringPrototypeNormalize
      2   33.3%    f:\BAK\prg\prg\nodes\node.master.exe

[bnoordhuis]

199 ticks, 192 unaccounted

I don't know what causes it but that's not good.

[vsemozhetbyt]

My tool versions: Visual C++ 2015 Build Tools v14.0.25420.1 (currently the same here), Python 2.7.13, Git for Windows 2.11.1.

Could anybody build with this configuration on Windows 7 x64 to check if the OS and tools combination is the problem or it is something in my other environment?

[vsemozhetbyt]

FWIW, here are the ill-starred binaries:

https://vsemozhetbyt.github.io/test/node.master.zip
https://vsemozhetbyt.github.io/test/node.vee-eight-lkgr.zip

[richardlau]

Are ~3-4 MB less.

This is about the size difference between the 32-bit and 64-bit binaries,
e.g. https://nodejs.org/download/nightly/v8.0.0-nightly201702211162e284ca/win-x64/
node.exe 21-Feb-2017 18:23 21588632
https://nodejs.org/download/nightly/v8.0.0-nightly201702211162e284ca/win-x86/
node.exe 21-Feb-2017 18:21 17493144

https://vsemozhetbyt.github.io/test/node.master.zip is 32-bit and is around a similar size to the 32-bit nightly.

> process.config.variables.target_arch
'ia32'
>

If you were expecting to build 64-bit, you'll need to pass x64 as an argument to vcbuild.bat.

FWIW, running the binaries on my Windows 10 system (I renamed the node.exe from the above nightly URLs):

C:\Users\ric\test>e:\Users\ric\Downloads\node-x64.exe time.js

// v8 5.5.372.40 (Node.js 8.0.0-nightly201702211162e284ca)

exec: 122.139ms
execSync: 449.230ms

C:\Users\ric\test>

C:\Users\ric\test>e:\Users\ric\Downloads\node-x86.exe time.js

// v8 5.5.372.40 (Node.js 8.0.0-nightly201702211162e284ca)

exec: 124.682ms
execSync: 676.219ms

C:\Users\ric\test>

C:\Users\ric\test>e:\Users\ric\Downloads\node.master.exe time.js

// v8 5.5.372.40 (Node.js 8.0.0-pre)

exec: 127.525ms
execSync: 665.003ms

C:\Users\ric\test>

[vsemozhetbyt]

@richardlau

If you were expecting to build 64-bit, you'll need to pass x64 as an argument to vcbuild.bat.

Thank you. So it should be .\vcbuild x64 test, right? Should not this be documented?

Is the node.master.exe in your test your build or mine?

According to your first two results, there should not be a big penalty in using 32bit Node on 64bit OS? But it could be a big penalty for building 32bit Node on 64bit OS?

[richardlau]

Thank you. So it should be .\vcbuild x64 test, right? Should not this be documented?

Yes, that should work. If it isn't already documented then yes, it should.

Is the node.master.exe in your test your build or mine?

Your build (from https://vsemozhetbyt.github.io/test/node.master.zip). I didn't build anything, just ran the binaries.

According to your first two results, there should not be a big penalty in using 32bit Node on 64bit OS? But it could be a big penalty for building 32bit Node on 64bit OS?

I dunno, those were the numbers I get on my home PC. Maybe you can try the 32-bit nightly and see if it produces similar numbers to your local build on your system?

[richardlau]

cc @nodejs/platform-windows

[vsemozhetbyt]

Oops. Two downloaded nightly:

  // v8 5.5.372.40 (Node.js 8.0.0-nightly201702211162e284ca ia32)

exec: 1685.541ms
execSync: 2364.786ms

  // v8 5.5.372.40 (Node.js 8.0.0-nightly201702211162e284ca x64)

exec: 328.099ms
execSync: 752.895ms

Is this expected performance downgrade?

[vsemozhetbyt]

I've built x64, here are two local build:

  // v8 5.5.372.40 (Node.js 8.0.0-pre ia32)

exec: 1699.096ms
execSync: 2357.636ms

  // v8 5.5.372.40 (Node.js 8.0.0-pre x64)

exec: 345.231ms
execSync: 753.990ms

So it is not building that affected, it is running. Is x32 Node.js equally slower on the Win 7 x32?

[seishun]

Is x32 Node.js equally slower on the Win 7 x32?

Slower than what? You can't run x64 on 32-bit Windows, so there wouldn't be a reference point.

IMO this is a non-issue. There is no reason why 32-bit builds should run fast on 64-bit Windows.

[vsemozhetbyt]

Slower than what?

Sorry) Slower than x64 Node.js in Win x64 on the same machine.

IMO this is a non-issue. There is no reason why 32-bit builds should run fast on 64-bit Windows.

Thank you. I will keep it open some time in case somebody wants to document the build parameter.

[targos]

I don't use Windows often for developments but IMO the default build should be x64. Why is it different than the unix builds?

[seishun]

vcbuild now defaults to x64. Regarding the documentation - isn't vcbuild help enough?

[vsemozhetbyt]

@seishun I know that the help key is almost a standard, but a small mention like 'Run vcbuild help to see all the keys' would be helpful, maybe)

[Trott]

This is still an issue and should remain open?

[vsemozhetbyt]

@Trott I have no strong opinion, but may be these two things would be helpful for beginners:

1. Mention of vcbuild help.
2. Note about default build architecture (x64).

[gireeshpunathil]

Let us invite doc contributions from interested parties - tagging accordingly, let me know if that is not the case.

[BridgeAR]

There was no activity for over half a year. vcbuild help is documented in doc/guides/maintaining-the-build-files.md (I guess it could be expanded but it's probably not necessary?).

Since no one picked this up and it's mainly internal, I am going to close this. If someone disagrees, please just go ahead and reopen.