-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
doc: adding estimated execution time #41142
Conversation
6eef97f
to
3b18d86
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I am not mistaken, there is a way to increase the speed of these commands by specifying that you would like to use more processor cores, but I don't remember what that command is or whether it is documented anywhere. If we don't have that neat trick documented anywhere, I think it would be good to do so.
Would anyone happen to know if/what option(s) to pass to increase this speed?
/cc @devsnek @codebytere 🙏
(This code might take more than an hour to execute on a PC, want to run a part | ||
of tests quickly or for more details see the [running tests][] section of | ||
Building guide.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This code might take more than an hour to execute on a PC, want to run a part | |
of tests quickly or for more details see the [running tests][] section of | |
Building guide.) | |
Running tests can take a long time. To run a subset of the test suite, see the | |
[running tests][] section of the Building guide. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with you there is no need for too much explanation here. I used the -j4
argument at run time, but it still takes more than an hour.So I thought it might be a good idea to add a numerical estimated time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please tell me what you think and finish the PR
@Trott
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what's the typical experience (and I'm not sure that anyone else does either) so I'm inclined to not try to specify a time and go with the suggestion I made above. However, if we think it would be helpful to include a running time, maybe something like this?: "Depending on your hardware, running tests might take an hour or more."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course I understand that time is hardware dependent, but based on my tests I don't think I can achieve results in less than an hour without a specialized compilation computer.
"Depending on your hardware, running tests might take an hour or more."maybe a good answer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On my Windows PC, it takes less than 15 minutes to compile and test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I exceeded more than an hour on both my Windows PC and Linux laptops and the laptop took a little longer. Maybe my hardware is too old?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using build time in CI as the standard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the text as it currently stands sufficiently covers things:
For some configurations, running all tests might take a long time (an hour or
more). To run a subset of the test suite, see the [running tests][] section of
the Building guide.
If that works for you, this can land. We have all the right approvals and CI is green.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem. I think the current version is pretty good
Not sure about As you can see by the bad job I've done explaining it here, it's easy to write a ton of text that most people will never need and is hard to understand. If we do end up going into detail on this, it should probably go inside a I've been on-and-off trying to get pre-compilation working with GitPod so new contributors don't have to compile at all, but I keep not following through. |
I just found my old Node Core notes that I took on the subject nearly a year ago… make -j{number of logical cores}
make -j8 These instructions would not be sufficient w/o first including the prerequisite that the person building Node first runs the
Refs: https://wiki.gentoo.org/wiki/MAKEOPTS We should probably document this, but probably in a separate PR. |
@DerekNonGeneric |
On Windows, the maximum number of parallelisation is used by default (which can make the system unresponsive sometimes). I don't remember how to change this. |
FWIW, building and testing debug (non-release) builds can take a long time, and |
Landed in e676942 |
PR-URL: #41142 Reviewed-By: Derek Lewis <DerekNonGeneric@inf.is> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Stewart X Addison <sxa@redhat.com>
PR-URL: #41142 Reviewed-By: Derek Lewis <DerekNonGeneric@inf.is> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Stewart X Addison <sxa@redhat.com>
PR-URL: nodejs#41142 Reviewed-By: Derek Lewis <DerekNonGeneric@inf.is> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Stewart X Addison <sxa@redhat.com>
PR-URL: #41142 Reviewed-By: Derek Lewis <DerekNonGeneric@inf.is> Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de> Reviewed-By: Stewart X Addison <sxa@redhat.com>
👋🏼 @Trott We can give it a try, for now, it works perfectly fine. |
Gitpod prebuild is great. I use gitpod a lot when I develop node core. It provides 16 core and 64 memory out of the box. |
I'd be curious what your .gitpod.yml file or other settings are. I have to do something mildly unintuitive to make it work and I wonder if I'm Doing It Wrong™, |
I dont have any .gitpod.yml and other setting. gitpod has almost everything I need to build node: gcc, clang, make, even ninja is also included. |
adding estimated execution times is more firendly for new contributer