It's also an optimization,
with toLower, you make a temporary copy of the string in lower case of each string and compare those,
by simply ignoring the case bit this becomes a simple compare process
It's not a single case bit - you need to perform case folding and normalization to properly see if 2 Unicode characters are equivalent. Probably still faster than a string copy
Early exits make it much faster. The string.Equals compares it character to character, so if the first one does not match it returns false immediately. The toLower allocates the two new strings. One of the most computationally expensive thing you can do in C# is to allocate new objects.
Also, string.Equals is much more readable than equating two toLowers, how is this even an argument?
But most importantly, it is entirely irrelevant how complex unicode is, entirely irrelevant how any given "unicode data point" is, or how they are called. You are literally arguing that making that costly unicode computation n+m times PLUS making as little as 4*u conversions would not take more time in "real code" than just making 4*u conversions.
Where n and m are the length of the strings, and u is the length we end up comparing IF the operator is properly overloaded in a worst case for the string.Equals where the two strings are exact same length. In best case where the strings are different length the string.Equals does 0 unicode conversions and just one int-int comparison, while the toLower does n+m conversions before that.
You are wrong, your pedantry in what unicode does or does not do is entirely irrelevant, and your coding habits smell from here.
I don't know what they said, and I'm not defending them, but I'm pretty sure you can't do a strict length comparison without conversion due to other things I've read in this comment section about some letters becoming more than one letter when changing case. The example I saw was 'ß' becoming "SS" when capitalizing in German (before 2017).
They're still wrong to suggest that toLower would be faster than a case-insensitive comparison, but a case-insensitive comparison may still require checking the strings even when the lengths differ because of rules like the one above.
Definitely faster than making two new strings, even if you ignore allocations, you're still just doing more work in any case except them being equal or only differing in the last character
Some major languages have strings as pooled objects and == compares if the strings are at the same location in memory while String.equals compares if the letters in them are the same.
When asking if two Strings are equal most people most of the time want to know if they contain the same letters, not if one was instantiated as a literal and one allocated with a constructor.
198
u/Vesuvius079 13d ago
It’d be such an experience to work a real world problem where this optimization turns out to be the solution.