How long are the strings in question? Is the "tokenizer.string = string" assignment itself slow or does it cause slowness down the road? If the former - how long (e.g. in µs) does it take and how long does the "==" take which you want to use for the test? Also you should consider how often will the == test take the "true" vs "false" path in practice for your data (99% compared to 1% could make a great deal of difference in the overall timing results).
Note that the string EQ is slowest when EQ operation can't use the quick path for some reason (comparing the underlying pointers which happen to be equal) but the strings themselves are equal. Or consider the two long strings that are equal up until the very last byte. For two random strings - EQ is typically fast (quickly returns false after comparing the lengths or the first few characters).
I asked a similar question some time ago, back then there was no known answer.
Also consider the following "quick positive" string equivalence check:
extension String {
/// quickly returns `true` if the two strings are definitely equal (the same thing)
/// may return `false` for two strings that are equal when compared with `==`
/// definitely returns `false` for two != strings
func isSame(_ other: String) -> Bool {
precondition(MemoryLayout<String>.size == 16)
let lhs = unsafeBitCast(self, to: (UInt64, UInt64).self)
let rhs = unsafeBitCast(other, to: (UInt64, UInt64).self)
return lhs == rhs
}
}
// usage:
if !tokenizer.string.isSame(newString) {
tokenizer.string = newString
}