We have an issue reviver (tools/github/reviver/) which revives issues that
still have pending TODOs remaining. Such revived issues are labeled with
"revived".
Currently the issue reviver workflow and stale workflow go in a loop closing
and re-opening issues every few months. Break this loop by not auto-closing
revived issues.
PiperOrigin-RevId: 624993203
The golang codeql has been failing for 4 months now. It is because CodeQL was
running with Go 1.20.14, but go.mod specifies v1.21.1.
PiperOrigin-RevId: 607007356
Starting with Go 1.21, build tags select the language version. We currently
have several `go:build go1.1` tags, which were intended to act as "true" tags.
But that will break with 1.21. So replace them with "!false".
Fixes#9568.
PiperOrigin-RevId: 576020779
Proposals usually have more longevity and contain interesting ideas.
Also clean up "new feature" and "enhancement" from the list. Those labels don't
exist in gVisor repo.
PiperOrigin-RevId: 565735357
This optimizes both increments and lookup operations.
It does so using the following:
- For metrics of potential cardinality larger than 48, it will switch to using
a map rather than linear search for mapping field value combinations to the
index that combination corresponds to in the flattened list of values.
For metrics of cardinality 48 or smaller, linear search is still used as it
is still faster (and also still faster than binary search), as determined by
benchmarks.
- All field values are checked for pointer uniqueness (i.e. the pointer to the
start of each field value string must be unique). This is then used for
faster matching: instead of comparing whole strings (and needing to hash
them, in the case of doing map-based lookups), it compares pointer values.
In the context of this metric library, because all field values must be
pre-declared ahead of time, keeping references to these pre-declared strings
should always be possible. This is enforced: it will `panic` if the metric
user does not do this. In practice, this is easy to do by using `const`
strings for all metric values. This change does just that for existing
metrics with string fields.
From benchmarks, this speeds up the time to take a snapshot of existing
metrics by -8.35%. With the unimplemented syscall counter metric, this
optimization reduces the slowdown of adding this metric from +4,250% to
a still-large but much more manageable +290%. A further optimization
(cl/524419591) will reduce this overhead further before re-introducing the
unimplemented syscall counter metric.
PiperOrigin-RevId: 526134756