Is this with 2017? If so, this is likely a dupe of  issue 755611 . Using either 2015 or not using fastlink is a workaround.

I haven't set any flags to change to 2017

https://chromium-review.googlesource.com/617764 doesn't help with the initial link (I didn't see 20 mins for that, but 10 min, which is still very long -- but I also didn't set is_win_fastlink , I haven't seen that making things faster locally, and maybe it makes things slower?), but it does speed up follow-on links to take 17s instead of 10min. It should also help in msvc builds.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/421a3c55c1173a59db3554920ccb39c9c145fb03

commit 421a3c55c1173a59db3554920ccb39c9c145fb03
Author: Nico Weber <thakis@chromium.org>
Date: Wed Aug 16 20:32:23 2017

win: enable incremental linking for large binaries in 32-bit builds.

ilk files are large in 64-bit builds and in non-component builds.
It looks like the conditional here has been wrong since it was
added in https://codereview.chromium.org/1019353004

I linked browser_tests locally, and ilk size is "only" a bit over
1GB, a lot smaller than blink_core.ilk, which we can successfully
link incrementally in 32-bit component builds. (I also checked
that browser_tests links fine incrementally.)

Bug:  755863 
Change-Id: If94c1d562d7e02b94a8cb899116479ff2d9ecd92
Reviewed-on: https://chromium-review.googlesource.com/617764
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Brett Wilson <brettw@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494926}
[modify] https://crrev.com/421a3c55c1173a59db3554920ccb39c9c145fb03/build/config/win/BUILD.gn

jam: Is this a regression, or did you try this for the first time since the clang switch?

Sorry not sure I understand your question?

Before clang switch, browser_tests with
is_debug = true
enable_nacl = false
target_cpu = "x86"
is_win_fastlink = true
used to link fast.

I may not have built browser_tests in the last few weeks, but now that I started again now I see it very slow.

Are you saying it could be unrelated to clang and just suddenly got worse for a different reason?

Yes, I'm asking if you've ever seen it be not slow with clang.

Since we switched to clang, I haven't built with msvc. I have only seen this issue since we switched.

Nico asked me on chat whether this happens with a fresh build. I synced (r495390) deleted out\Debug and rebuilt. I then changed one file  (chrome\browser\io_thread_browsertest.cc) and built browser_tests again. It took 24 minutes.

I believe the Clang roll this morning, which included Zach's r312583 fixed this.

Using the gn args in #7 + use_goma=true is_clang=true, I did a clean build of browser_tests, touched the file mentioned in #11 and re-built:

C:\src\chromium\src>time /t && ninja -C out/debug -j500 browser_tests && time /t
03:54 PM
ninja: Entering directory `out/debug'
[2/2] LINK browser_tests.exe browser_tests.exe.pdb
03:55 PM

I also verified that before the roll it was really slow (I gave up after 8 minutes of linking).