Skip to content
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

Possible Enhacement Idea #126

Open
amishscientist opened this issue Aug 18, 2021 · 5 comments
Open

Possible Enhacement Idea #126

amishscientist opened this issue Aug 18, 2021 · 5 comments

Comments

@amishscientist
Copy link

When I first look at a build to profile I normally find the box with the most cores on it and run /usr/bin/time -v make -j NumOfCPU

I then look at Percent of CPU this job got: in the output of time from the build command. If it is close to the number of cores I gave the make command then I know I can probably look into things like dist_cc or icecreamcc to get faster builds, but if I gave that thing 24 cores and it only got a 800% then things like dist_cc or icecreamcc aren't going to do any good because I couldn't even uses all the cores on my current box all the way.

It might be nice if remake could give us some data or stats on how busy the make job queue is during the build. Average Job Queue length, How much time it spent with a full job queue and maybe if it never hit the max number of jobs in the queue.

@rocky
Copy link
Owner

rocky commented Aug 18, 2021

This is open-source software, so feel free to experiment and implement what you suggest.

@amishscientist
Copy link
Author

Any idea where a good place to start would be?

@rocky
Copy link
Owner

rocky commented Aug 19, 2021

Here is a guess, first try to do this totally externally. If you can't, then describe what thing internally would make this work.

In my opinion being able to describe in pseudo code how things would work would help. Pretend you are the computer you see x so you do y, and so on.

But if you are a low-level kind of guy then src/job.c is where all "jobs" or external commands that get run is kicked off from.

@Arrowbox
Copy link

Arrowbox commented Oct 1, 2021

If you check out the json_output branch, I also capture the -j value. I've been working on dumping the same information about parallelness. My current approach is to sum all the time taken running recipes and divide that by total wall time. If it perfectly scaled, then recipe/total = number of cores.

@martencassel
Copy link

Here is a guess, first try to do this totally externally. If you can't, then describe what thing internally would make this work.

In my opinion being able to describe in pseudo code how things would work would help. Pretend you are the computer you see x so you do y, and so on.

But if you are a low-level kind of guy then src/job.c is where all "jobs" or external commands that get run is kicked off from.

rocky tip is an epic one.. on the mindset to have when hacking up code.... very helpful to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants