DiligentGraphics / DiligentCore

A modern cross-platform low-level graphics API
http://diligentgraphics.com/diligent-engine/
Apache License 2.0
635 stars 138 forks source link

Remove viral /GL option #620

Closed canadacow closed 3 months ago

canadacow commented 3 months ago

Was wondering why my build times went from seconds to more than a minute just changing a single file in my build project. It's because DiligentCore enables whole program optimization with MSVC, i.e. /GL.

26>cmake_pch.obj : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
26>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification

And given the size of the rest of my project, linking times end up being dramatically inflated.

I don't know of a way to disable compilation options in cmake fetched projects. And neither does the AI from what I can gather. If you have any ideas how to do this within my own CMakeLists.txt that would be extremely helpful, otherwise I'd recommend turning this option off so as to not inflate link times in projects importing Diligent.

TheMostDiligent commented 3 months ago

Release configuration is intended to build final shipping product where performance is critical. Whole program optimization does increase link time, but it is totally worth it as it may improve performance by as much as 10%. Your change unconditionally disables this option, which will result in a degraded performance for all projects using Diligent, so it clearly is unacceptable. A correct solution is to allow optionally turning this option off using the DILIGENT_MSVC_RELEASE_COMPILE_OPTIONS CMake variable (80b92e910dbdbcc8e1fcafae49bb86e5cb242f99)

canadacow commented 3 months ago

Thanks for providing the workaround.

Whole program optimization does increase link time, but it is totally worth it as it may improve performance by as much as 10%.

https://devblogs.microsoft.com/cppblog/quick-tips-on-using-whole-program-optimization/

"If you’re writing native C++ code, you can typically speed up your optimized code by about another 3-4% by adding the /GL flag to your compiles."

Official numbers are around 3-4%. Is that worth an extra minute of build time every time I want to change the case of a variable? I don't know.

FWIW, the shadowmap initialization code in a Debug build takes about a 30 seconds to initialize, even on a current CPU/GPU combo.

So my choices (before the change) are run in Release and wait an extra minute for the whole program optimization to complete, or wait 30 seconds for the SSR to wake up. Either way, it's a poor developer experience, hence the rabbit hole to find where the minute was being spent building release.

TheMostDiligent commented 3 months ago

the shadowmap initialization code in a Debug build takes about a 30 seconds to initialize

What do you do that takes so much time?