On Mon, Sep 23, 2013 at 12:49 AM, Robert O'Callahan <rob...@ocallahan.org>wrote:
> I observe that Visual Studio builds do not spawn one cl process per > translation unit. Knowing how slow Windows is at spawning processes, I > suspect the build would be a lot faster if we used a single cl process to > compile multiple tranlation units. > > /MP apparently spawns multiple processes to compile a set of files. That's > kind of the opposite of what we want here. > > I see how compiling several files in the same cl invocation would mess up > using /showincludes to track dependencies, making this difficult to fix. > The only possibility I can think of for fixing this is to emit a Visual > Studio project and make the Visual Studio builder responsible for tracking > #include dependencies. > > Vlad Ehsan and I did just that. With hacky.mk you can generate a fully working Visual Studio project which will let you make changes to XUL as necessary. The problem with MSBuild used by VS is that invokes one process at a time. So as soon as a group of files requires different flags (and we aren't even closed to having unified build flag across the tree) they require a separate invocation of cl.exe by MSBuild and so you end up with several invocation of cl.exe running serially and your CPU utilization is far from 100% as the first cl.exe invocation is down to the last 1-2 remaining object file before the next invocation can start. It takes over an hour to build with VS using hacky.mk. The benefit of specifying a working VS solution is perfect intellisense. For building it's better to call a good external build system from your IDE. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
