commit 2e75a5498d62b17168538e8e7d6da3371ebd4426
author Konstantin Shcheglov <scheglov@google.com> Mon Sep 29 09:50:32 2025 -0700
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Mon Sep 29 09:50:32 2025 -0700
tree a8d407f62852572b7bce8b050185a6d37c0ab5ca
parent 1b8bcf23f749174e04e09c355c9cd4ed07e86b45

Fine. Add set metric to OperationPerformance; track detail URIs

Introduce a generic set-based performance datum and use it to record the
distinct libraries that require a full requirements check.

Changes:
- Add `OperationPerformanceDataImpl_Set<T>` which stores unique values and
  formats as `name: <count>` to keep logs compact. Includes `add(T)` to
  insert items.
- Add `OperationPerformanceImpl.getDataSet<T>(name)` to access/create set
  metrics, mirroring `getDataInt`.
- In `RequirementsManifest.isSatisfied`, when a library’s
  `hashForRequirements` does not match the manifest, continue to increment
  `libDetails` and also add the library URI to the new `libDetailsUris` set.

Why:
- Distinguishes total detail checks (`libDetails`) from the number of
  distinct libraries involved (`libDetailsUris`). This makes it easier to
  diagnose fine-grained dependency behavior (e.g., a few libraries causing
  many checks vs. many libraries each checked once).
- Avoids verbose logs by printing only the set’s size.

Impact:
- No functional changes to analysis; only additional metrics are recorded.
- Existing counters (`libHash`, `libDetails`) remain unchanged and
  compatible with current log consumers.

Limitations:
- The current `OperationPerformance` design and naming are not ideal. This
  change follows the existing pattern but increases the motivation to
  refactor and simplify the API and names in a follow-up.

Change-Id: Ic677e28b9ae98190ddc0243ac0cea01aa44e736f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/451940
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>