-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor lib.TagSet to use a bitmask/bitset #755
Comments
Merged
As an aside, while the bit mask can be trivially implemented by iotas, at least until we have more than 64 flags, the marshaling and unmarshaling of string values should probably happen with some sort of a go-generated code, like how we use enumer for the response types and the compression types. |
cuonglm
added a commit
that referenced
this issue
Sep 9, 2019
Add tag set as a bitmask, as part of refactoring lib.TagSet. Update #755
Merged
cuonglm
added a commit
that referenced
this issue
Sep 27, 2019
Add tag set as a bitmask, as part of refactoring lib.TagSet. Update #755
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Probably not a huge deal in terms of performance, but the
TagSet
type would be much better if implemented as a bitmask/bitset (or even a plain old struct withbool
fields) instead of the currentmap[string]bool
.We know all of the possible system tag values at compile time and we check the enabled values every time we build the tags for a metric, which would be much quicker without all of the map lookups. And making the system tag IDs in code be constants (with
1 << iota
) instead of strings would probably reduce the probability of human errors when dealing with them. The only time we should use the string IDs is when we parse the user-given configuration (or inject the consolidated configuration back into the script).The text was updated successfully, but these errors were encountered: