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

Optimize containsAll Method for Improved Performance #32453

Conversation

alidandach
Copy link
Contributor

This pull request introduces an optimization to the containsAll method in collection handling. It is aim to improve the method's performance, especially when dealing with large collections.

Previously, the containsAll method used this.backingList.containsAll(c), iterating over each element in the collection c and checking for its presence in this.backingList. This approach, while straightforward, can lead to suboptimal performance for large collections due to the potential for repeated linear searches.

This change has 2 benefits:

  • Improved Performance: This change significantly reduces the computational complexity of the containsAll method, especially beneficial when this.backingList and c are large.
  • Scalability: As the size of the collections grows, the performance benefits of this optimization become even more pronounced, making collection handling more scalable.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 15, 2024
@jhoeller
Copy link
Contributor

In general, we don't apply such optimizations in our own collection adapters. Such a HashSet-based access pattern is better off in the caller where the Set adapter can possibly be reused for several operations etc. Decorators from an outer List to an inner List are not really meant to optimize that behavior.

From a caller's perspective, AutoPopulatingList is an arbitrary List: so when the caller performs a containsAll call on it, standard List performance characteristics are expected. A caller might even apply a HashSet-based access pattern already, leading to inefficient double wrapping when we internally do it as well.

@jhoeller jhoeller closed this Mar 15, 2024
@jhoeller jhoeller added status: declined A suggestion or change that we don't feel we should currently apply and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Mar 15, 2024
@alidandach alidandach deleted the enhancement/optimize-containsAll-performance branch March 15, 2024 12:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants