tree eed3170638cda94a77cbfaf287d6f6729623c13b
parent 844bbe7cf8c8bf3dd2678c4b1f3a001af295f7ee
author Takuto Ikuta <tikuta@google.com> 1779250087 +0900
committer gn-scoped@luci-project-accounts.iam.gserviceaccount.com <gn-scoped@luci-project-accounts.iam.gserviceaccount.com> 1779251479 -0700

Reduce ResolvedTargetData lock contention by sharding targets map

In the parallel writing phase of 'gn gen', multiple threads access a
single 'std::shared_mutex' and 'UniqueVector' inside ResolvedTargetData
at high frequency. Although shared locks (read locks) are used, the
atomic reference count operations within the shared mutex cause massive
cache line bouncing (lock contention) on multi-core systems, severely
degrading parallel performance.

To resolve this, this CL shards the shared targets map and its mutex
into 128 independent shards. We also use std::hash to distribute targets
evenly across shards and avoid pointer alignment biases (which would
happen with simple pointer bit shifts).

We conducted hyperfine benchmarks on Chromium 'out/Default' across
different shard counts to find the optimal value, compared to the
original baseline:
- Base (No sharding, 1 lock): 2.716s ± 0.059s
- 8 shards: 2.723s ± 0.056s (Lock contention unresolved)
- 16 shards: 2.755s ± 0.096s
- 32 shards: 2.495s ± 0.011s (approx. 8.1% faster than Base)
- 64 shards: 2.531s ± 0.062s
- 128 shards: 2.443s ± 0.089s (approx. 10.0% faster than Base / -0.27s, Optimal spot)
- 256 shards: 2.507s ± 0.064s
- 512 shards: 2.523s ± 0.093s
- 1024 shards: 2.534s ± 0.073s

128 shards is chosen as it provides the best performance scaling for
high-core workstations while keeping minimal memory overhead.

Cumulative CPU time of 'file_write_ninja' phase: approx. 33% reduction.

Bug: 502431091
Change-Id: I366057a87e17e3438f028e1142928ba55e47dc69
Reviewed-on: https://gn-review.googlesource.com/c/gn/+/22801
Reviewed-by: Matt Stark <msta@google.com>
Commit-Queue: Takuto Ikuta <tikuta@google.com>