There's a longstanding problem in implementing `-isEqualToString:`,
where if you don't know how to get fast access to the other NSString's
contents, you have to pick between doing it character by character (very
slow), or calling [other isEqualToString: self], which risks infinite
recursion if the other string does the same.
This cuts the gordian knot by adding a new method
`isEqualToBytes:encoding:count:`, so you can get the contents out of
`self`, and hand it to the other string, confident that it will not need
to (nor, in fact be able to) ask you anything that might recurse.
rdar://172192966
The tasks of a task group were stored in a singly linked list, causing a
linear scan for a task to find its predecessor, whenever a task completed
and had to be removed from the list. This change turns it into a doubly
linked list, so the linear scan is avoided completely.
The inlinable certainly wont hurt on these "forwarding" methods, though
I was not able to confirm a noticable difference at least using this
benchmark.
Since adding those is definitely good anyway, I didn't dig much further,
let's just add them.
Assisted by: claude to make the benchmark, manually verified all changes
ran benchmarks and checked results etc
This changes the implementation for `Collection.difference(from:)` to
use a linear-space complexity variation of the same Myers algorithm. The
new version is similar in execution time to the existing one, but should
alleviate memory pressure when diffing collections where the number of
differences approaches the size of the collection. While the new
algorithm returns a set of changes that is the same size as the previous
version, the specific changes are not guaranteed to be the same.
rdar://155829876
Enabling both of these despite the long runtime so that I can get an
accurate measure of the change with the new diffing implementation.
After #83212 is merged I will disable these large benchmarks again.
Fix warning in benchmark: generic parameter 'C' shadows generic parameter from outer scope with the same name; this is an error in the Swift 6 language mode
The _StringProcessing module provides a generic, collection-based
`contains` method that performs poorly for ranges and closed ranges.
This addresses the primary issue by providing concrete overloads
for Range and ClosedRange which match the expected performance for
these operations.
This change also fixes an issue with the existing range overlap tests.
The generated `(Closed)Range.overlap` tests are ignoring the "other"
range type when generating ranges for testing, so all overlap tests
are only being run against ranges of the same type. This fixes things
so that heterogeneous testing is included.
* Revert "Revert count(where:)"
This reverts commit 779ea19a6a.
Now that SE-0220 has been re-accepted, this adds the `count(where:)`
Sequence method to the standard library.
The optimizer managed to eliminate this entire benchmark,
resulting in useless 0 second timings.
I made a couple of changes to ensure the optimizer cannot
eliminate the loop:
* The individual checks now actually use the loop parameter
* `identity()` is used to ensure conservatism
While here, I reduced the loop count since these benchmarks seem
to run for a long time.