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
msbuild: Merge "Core" libs into single DolphinLib #9092
Conversation
|
It might be a good idea to rename "VulkanContext" to "VKContext" for consistency |
|
I obey the linter |
|
@shuffle2 I assume that for the same reason, the D3D11backend has to be called just D3D? |
|
substantive/constructive comments appreciated ... |
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.
The sheer number of files changed by the renaming is probably putting off a lot of reviewers (myself included, I ignored it until now because I didn't feel like it).
Do you have any numbers comparing before/after, like full rebuild time, compile/link time, binary size (if that even changes in any way), etc...?
|
It was too long ago now, I'll have to redo the perf traces and get back about exact numbers, but it cut full rebuild time for me into about half iirc (amd 3990x). Anyone can look themselves with vcperf. |
a937011
to
99f216b
Compare
|
Some simple perf stats of running the following for both current master and this PR: master: PR: The MSBuild overall time is about 1/3 of master, resulting in overall clean build time of about 1/2 (CL becomes the long pole). fwiw, the actual wall-clock times: |
It was lost in dolphin-emu#9092.
For a long time, dolphin (on msbuild at least) has been building all of the "Dolphin Core" code with identical compilation settings.
This PR takes the next logical step and actually sends all source files to the compiler in a single batch. This itself is a build speedup.
Another build speedup comes from cutting out some unnecessary
libcalls, since all the resulting "core" object files get packaged into a single lib file. This should especially help buildbot/machines with few threads, since otherwise the lib step acts like a bubble in the msbuild pipeline (this is a legitimate failing of msbuild!).Another side effect is that the msbuild project dependency graph becomes almost flat, which also improves build parallelism (really, can be attributed to the same msbuild fail as the lib thing).
I'm currently investigating if it's possible for ninja to perform batched compiler invocations, and while I see people requesting/working on the feature over the years, I don't think it's actually implemented yet(?). Anyway, hopefully we can eventually do it for ninja/msvc. The batching would still be a speedup for ninja builds, but the speedup from lib reduction would probably not be as noticeable.
A prerequisite for bundling all the source files together is that they all have unique basenames. All of the commits except the final one are just accomplishing that. In most cases I think it also results in better style anyway.
I think with this PR and #9081 , the only realistic + meaningful remaining speedup for windows buildbot (without giving it better compute resources) is passing
/mto msbuild (because currentlylinkof multiple projects is serialized), but that change would have to be done in sadm.