nishantmehta opened a new pull request, #1735:
URL: https://github.com/apache/commons-lang/pull/1735
## Summary
`StringUtils.indexOfAnyBut(CharSequence, CharSequence)` — which backs
`containsOnly` and is also called directly — collected the search characters
into a `Set<Integer>` on **every call**:
```java
final Set<Integer> searchSetCodePoints =
searchChars.codePoints().boxed().collect(Collectors.toSet());
```
allocating an `IntStream`, a boxed `Stream<Integer>`, the boxed `Integer`
elements and a `HashSet` just to test membership while scanning the input.
This scans the search characters directly for each code point instead,
matching the existing nested-scan approach already used by
`containsAny`/`containsNone` in this same class. Iterating by code point
preserves supplementary-character (surrogate-pair) correctness, so behavior is
unchanged.
## Measurement
ThreadMXBean allocation driver, 300k warmed ops:
| call | before | after |
|------|--------|-------|
| `containsOnly("Hello, World!", ...)` | 744 B/op | 55 B/op (~4× faster) |
| `containsOnly(numeric25, digits)` | 744 B/op | 40 B/op (~3× faster) |
The residual ~40 B/op is the `char[]`/`CharBuffer` in the `String` overload.
## Testing
`StringUtilsTest`, `StringUtilsContainsTest` and `StringUtilsIndexOfTest`
pass unchanged (266 tests).
## Notes
Like the sibling `containsAny`/`containsNone`, the direct scan is O(n·m);
for the typical small `searchChars` it is both faster and allocation-free, and
it is consistent with how those neighbours are already implemented.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
