I built target 'chrome', first fully, by running this three times:

time ninja -C out/gn -j1000 chrome -t clean
time ninja -C out/gn -j1000 chrome

Then I tested incremental builds of content by running this three times:

touch content/child/child_process.cc
time ninja -C out/gn -j1000 chrome

Then blink_core (3x as well):

ttouch third_party/WebKit/Source/core/paint/ListMarkerPainter.cpp
time ninja -C out/gn -j1000 chrome

Finally chrome (3x):

touch chrome/browser/browser_process.cc
time ninja -C out/gn -j1000 chrome


I first did this with this args.gn:
use_goma = true

Then I repeated everything with this args.gn:
use_goma = true
use_lld = true


Here are the numbers:

gold:
full: 6m1.0s, 4m17.6s, 3m51.6s 4m38s (I had to sync and start over after the 3rd build, so take the first 3 numbers with a grain of salt; everything else is at #480858)
content incremental: 19.3, 18.5, 17.9, 17.6
blink_core incremental:  19.0, 18.9 (only did this twice)
chrome incremental: 32s, 31.9s

lld:
full: 6m3.7s, 5m31.6s, 5m15s
content incremental: 22.2s, 22.21s, 22.4s
blink_core incremental:  49.1s, 49.6s, 48.1s
chrome incremental: 36.1s, 35.2s, 33.6s9s


So in full builds, lld seems to benefit less from disk cache warm-up. In incremental builds, where ninja will only call clang for one cc file, and then lld for one link, lld is between 15% and 157% slower.

Given that lld is supposed to be much faster than gold, this surprised me. Maybe its debug fission emission code hasn't been tuned much yet?

(I filed  issue 735101  about lld printing a few warnings during the build.)