Skip to content
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

Avoid using sets when existing slices suffice #1719

Merged
merged 1 commit into from
Jul 8, 2024

Conversation

skitt
Copy link
Member

@skitt skitt commented Apr 15, 2024

Now that Go includes slice operations such as slices.Contains, some uses of sets are no longer useful. In particular, creating a set using a slice just to check whether the slice contains a specific item is more expensive than checking the slice directly.

}

// the object might be getting deleted
tombstone, ok := obj.(cache.DeletedFinalStateUnknown)
if ok {
if ns, ok := tombstone.Obj.(*corev1.Namespace); ok {
return interestingNamespacesSet.Has(ns.Name)
return slices.Contains(interestingNamespaces, ns.Name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm in favor of using slices.Contains instead of constructs like:

sets.New(HostnameMatchSpecCandidates(hostname)...).Has(matchSpec)

But I'm not sure about cases like this one, as we're going from O(1) to O(n) and I'm not sure how often these are called.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That’s a good point, the checker is used in an informer so slices don’t suffice here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ve restored two uses of sets where performance might matter.

Now that Go includes slice operations such as slices.Contains, some
uses of sets are no longer useful. In particular, creating a set using
a slice just to check whether the slice contains a specific item is
more expensive than checking the slice directly.

Signed-off-by: Stephen Kitt <skitt@redhat.com>
@dusk125
Copy link
Contributor

dusk125 commented Jun 24, 2024

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jun 24, 2024
@deads2k
Copy link
Contributor

deads2k commented Jul 8, 2024

/approve

Copy link
Contributor

openshift-ci bot commented Jul 8, 2024

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: deads2k, dusk125, skitt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 8, 2024
Copy link
Contributor

openshift-ci bot commented Jul 8, 2024

@skitt: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@openshift-merge-bot openshift-merge-bot bot merged commit aee040b into openshift:master Jul 8, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants