Code-Review | +1 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Commit-Queue | +2 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
2 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
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.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |