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

Incredibuild (or other distributed compilation) support #33

Open
mateberes opened this issue Aug 6, 2022 · 1 comment
Open

Incredibuild (or other distributed compilation) support #33

mateberes opened this issue Aug 6, 2022 · 1 comment
Labels
question Further information is requested

Comments

@mateberes
Copy link

Currently when I build a project with IB, CompileScore will only show the results from my machine, so I can choose between partial data, or a 7 hours build time.
Is it possible to add Incredibuild support? Awesome plugin btw.

@Viladoman
Copy link
Owner

First of all, thanks for using the extension.

I am assuming you are using MSVC to build your project. In this case the method Microsoft has created to extract the build events is by capturing them at the OS level afaik. This means that while a build recording is happening, anything that MSVC will compile in your machine will be captured. This has the following traits:

  • It is great as it will work under any build system, internal or external to Visual Studio, even recording from the command line, without having to change anything ( no extra compiler flags ).
  • Anything built on a helper machine somewhere else won't be recorded
  • A compilation triggered on a different machine but with some sources built on your machine as a helper in a distributed system will sneak into your recording.
  • Building 2 different solutions at the same time on the local machine will have both data merged together in the recording.

With distributed builds, there are 2 problems that need to be solved:

  • Knowing which Translation Unit belonged to which project or solution job.
  • Making the distributed build system to return extra processed data ( like some sort of local report for those files that we should be able to merge together later )

For clang the solution should be easier, as the way it reports the profiling data is by generating a .json file next to the .obj file. This means that we should only need a way to migrate back that file from the helper machine.

Sorry for the bad news, but what I have done in the past for massive projects is to leverage the fact that usually those projects have a nice server infrastructure in the company. We can then perform a nightly/weekend full non distributed compilation on the servers and store the data in a shared folder. Then we can make the extension point to that location and have 'up to date' build data without doing any extra action. This also opens the door to have some nice telemetry data and even add alerts when big changes happen, or weekly reports with the hotspots that should be addressed.

If you are interested in that approach I would recommend checking the command line score generation wiki page.

I hope this helps. If you have any ideas on how to deal better with distributed builds I would be more than happy to listen.

@Viladoman Viladoman added the question Further information is requested label Aug 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants