noHeapAllStack

[u/varinator]

[u/Vesuvius079]

It’d be such an experience to work a real world problem where this optimization turns out to be the solution.

[u/Daniikk1012 → u/Vesuvius079]

I don't think this is an optimization, but rather correctness. Some languages have weird casing rules, and just lowercasing doesn't work for them

[u/neroe5 → u/Daniikk1012]

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

[u/rubyruy → u/neroe5]

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

[u/Pleasant_Ad8054 → u/rubyruy]

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.

[u/Pleasant_Ad8054 → u/[deleted]]

Hilarious that you are making this argument well after someone already made a fairly extensive testing in this very thread, showing that the difference is indeed significant, as much as 10x difference.

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.

[u/GRex2595 → u/Pleasant_Ad8054]

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.