Linking time (Windows) and GBD loading time

[RenderMonkey]

I have a decent machine Windows 10 machine (i7-4790K 4 GHz, 16 GB RAM, 500 GB SSD) and linking cef / libcef in VS have always been slow for me in the previous branches (around 3 mins).
I never thought much about it since I rarely have to tinker in the CEF / chromium code, mostly I only do it when we upgrade to a new CEF branch since generally our own patches are always broke after the upgrade.
However with the latest branch (2840) the linking times have increased to roughly 8 mins which is sort of frustrating to say the least.. Does anyone else have this problem? I don't use GN_DEFINES=is_win_fastlink=true since I want to be able to build both debug and release builds. Is there some setting I am missing or that I can try that might improve this?

On my Linux machines (which is an older machine with an SSD disk) the linking time is pretty much instant (a few seconds) but my problem here is that I find it pretty much impossible to efficiently debug our Linux build in GDB since loading the libcef.so (which is over 1.5 GB) takes about the same time it takes to link libcef in Windows so I pretty much avoid using GDB and try to rely on logging messages but this can only get you so far sometimes... Running the debug build in VS on Windows is pretty much instant for me. Does anyone else have this problem?

Appreciate all input!

[magreenblatt]

The is_win_fastlink=true setting is your best option for fast local debug builds. If you're distributing the release builds then you should use the is_official_build=true setting: https://bitbucket.org/chromiumembedded/ ... figuration

If you want to create both fastlink debug builds and official release builds in the same checkout then you can manually create additional src/out directories with appropriate args.gn files.