-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: make build faster (at least on Windows) #12281
Comments
/cc @nodejs/build @nodejs/platform-windows |
|
🙏may the powers that be protect us from the evil that is |
Was thinking of rewriting it |
Hmm, not sure what the rest of @nodejs/build and @nodejs/platform-windows would think of that, but it sounds like it might be a good idea to me. Fundamentally I think people would be more willing to learn and contribute to a Or maybe we should write it in js... |
Actually could be |
Timing example, after applying #12511 (a change in C:\code\node>time < nul&vcbuild > nul&time < nul
The current time is: 14:07:53.76
Enter the new time: The current time is: 14:23:41.10
Enter the new time: ~16 minutes |
Is that faster or slower than the before time? |
Just an example of a recompile after just changing a Mean while on "Ubuntu on Windows" refael@refaelux:/mnt/d/code/node$ time BUILDTYPE=Debug make -C out -j3
make: Entering directory '/mnt/d/code/node/out'
ACTION Regenerating Makefile
-fmake --ignore-environment --toplevel-dir=. -I/mnt/d/code/node/common.gypi -I/mnt/d/code/node/config.gypi --depth=. -Goutput_dir=/mnt/d/code/node/out --generator-output=/mnt/d/code/node/out -Dcomponent=static_library -Dlibrary=static_library -Dlinux_use_bundled_binutils=0 -Dlinux_use_bundled_gold=0 -Dlinux_use_gold_flags=0 node.gyp /mnt/d/code/node/node.gyp -I /mnt/d/code/node/common.gypi -I /mnt/d/code/node/config.gypi --depth=. --generator-output /mnt/d/code/node/out -Goutput_dir=/mnt/d/code/node/out -Dcomponent=static_library -Dlibrary=static_library -Dlinux_use_bundled_binutils=0 -Dlinux_use_bundled_gold=0 -Dlinux_use_gold_flags=0
ACTION _mnt_d_code_node_node_gyp_node_js2c_host_node_js2c /mnt/d/code/node/out/Debug/obj/gen/node_javascript.cc
TOUCH 77ac9600461e1dfdf3594f5e11b3cd135d0cbfd6.intermediate
ACTION Generating inspector protocol sources from protocol json 77ac9600461e1dfdf3594f5e11b3cd135d0cbfd6.intermediate
CXX(target) /mnt/d/code/node/out/Debug/obj.target/node/gen/node_javascript.o
LINK(target) /mnt/d/code/node/out/Debug/node
rm 77ac9600461e1dfdf3594f5e11b3cd135d0cbfd6.intermediate
make: Leaving directory '/mnt/d/code/node/out'
real 1m25.091s
user 0m45.625s
sys 0m33.406s [linux envy] |
Not that much faster for me on Linux. C++ linking of Debug symbols is brutal. I worked with a program that had a 45 minute non-debug linktime once. Debug couldn't be linked, not enough memory on our machines. |
Same scenario, just changing a c:\code\node\out.ninja\out\Debug$ time < nul &echo.""&ninja -j 3 -v -f build.ninja node&time < nul
The current time is: 18:50:11.05
Enter the new time: ""
[1/5] C:\bin\dev\python27\python.exe gyp-win-tool action-wrapper environment.x64 node_js2c_target_node_js2c_bce0facc3e66b523ccf35ab2d859c2d9..rsp ..\..\..\
[2/5] C:\bin\dev\python27\python.exe gyp-win-tool stamp obj\node.actions_depends.stamp
[3/5] C:\bin\dev\python27\python.exe gyp-win-tool stamp obj\node.compile_depends.stamp
[4/5] ninja -t msvc -e environment.x64 -- "D:\bin\dev\VS\2017\BuildTools\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe" /nologo /showIncludes /FC @obj\gen\node.node_javascript.obj.rsp /c gen\node_javascript.cc /Foobj\gen\node.node_javascript.obj /Fdobj\node.cc.pdb
[5/5] C:\bin\dev\python27\python.exe gyp-win-tool link-with-manifests environment.x64 True node.exe "C:\bin\dev\python27\python.exe gyp-win-tool link-wrapper environment.x64 False link.exe /nologo /OUT:node.exe @node.exe.rsp" 1 mt.exe rc.exe "obj\node.node.exe.intermediate.manifest" obj\node.node.exe.generated.manifest ..\..\..\src\res\node.exe.extra.manifest
The current time is: 18:51:07.85
Enter the new time: 56 seconds. I'm in love with ninja |
@refack
@rsam I think the 16 minutes was for release mode on windows looking at the command: |
On a fully pre-built tree, after changing one |
Ah, I though |
This is something I wanted to build myself (maybe into |
@refack maybe try https://github.com/frerich/clcache ? |
this is a backport of 4 gyp commits since last bump, syncing us to https://chromium.googlesource.com/external/gyp/+/a478c1ab51ea3e04e79791ac3d1dad01b3f57434 this is instead of a bump and rebase of floating patches the goal is to fix the ninja generator on Windows also includes: * windows: use "mkdir" even when copying directory Original commit messages: a478c1ab51ea3e04e79791ac3d1dad01b3f57434: win: mkdir even when copying directory * also "fix" the paths in the message * un-skip test/copies/gyptest-all.py BUG=gyp:536 Change-Id: Id8ff7941b995c25d68d454138cd8b04940fdd82b Reviewed-on: https://chromium-review.googlesource.com/487521 Commit-Queue: Dirk Pranke <dpranke@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> ffd524cefaad622e72995e852ffb0b18e83f8054 win ninja/make: Always use a native compiler executable with MSVS 2017 A host-native executable will always be used, and it will be a cross compiler if the target architecture differs from the host architecture. BUG=683729 Change-Id: I02a09e1755dd2ab7eca5c9d1957d7aeb56db6af6 Reviewed-on: https://chromium-review.googlesource.com/486400 Commit-Queue: Mark Mentovai <mark@chromium.org> Reviewed-by: Dirk Pranke <dpranke@chromium.org> e8850240a433259052705fb8c56e51795b7dc9c3 Fix MSVC++ 32-on-32 builds after b62d04ff85e6 BUG=683729 Change-Id: Ic8c227960b859ddc3c19fce0e98144510f5e74bf Reviewed-on: https://chromium-review.googlesource.com/486380 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Commit-Queue: Mark Mentovai <mark@chromium.org> b62d04ff85e6234e4fec7fff9377dd96c09d41a7 win,ninja: ninja generator better on windows * add compatibility with VS2017 * adjust `_TargetConfig` and `/FS` for VS2017 compat * find new place of `vcvarsall.bat` in VS2017 * normalize "path like" arguments of actions * better check for `.lib` and `.def` file names BUG=683729 Change-Id: I123bff7bd8a0011cf65d27a62b5267ba884e3b42 Reviewed-on: https://chromium-review.googlesource.com/482580 Reviewed-by: Dirk Pranke <dpranke@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org> Commit-Queue: Dirk Pranke <dpranke@chromium.org> Ref: nodejs#12281 PR-URL: nodejs#12632
Should this remain open? If so, does it make sense to make it a tracking issue with some check boxes so it's obvious at a glance what parts are done and what parts aren't? |
Don't triagathon me 👼 |
/cc @nodejs/platform-windows now that we've grown in numbers, and at @Trott's behest, I've broken this issue down to several more tractable tasks. I'd be happy if we all pitched in (I've given most of the tasks some thought, but not enough work, so I'd be happy to discuss each of them). |
I would prefer Powershell over JScript. |
Yep, that's #12310 (I'm 80% there, just 80% more left) - https://gist.github.com/refack/969ecc6642981bfd7caef7d948d78076 |
There's been no further discussion in years with no clear action here. Closing. |
The problem: even for minor changes building on Windows can take 10s of minutes.
This issue is for tracking several approaches to mitigate that.
GYP
less aggressive in recreating *.*proj filesninja
simpler/lib/
files as is (skipmksnapshot
)/deps/
from main executable compilation & linkingThe text was updated successfully, but these errors were encountered: