From their brief summary descriptions, it sounds like the string comparison rules StringComparison.Ordinal
and StringComparison.InvariantCulture
ar
Well, it certainly matters. When you use an "ignore case" equality comparison then you're invoking a fairly massive chunk of code in the .NET framework that's aware of how casing rules work in the current culture. The rules of which are very interesting to a former-postage-stamp collector geek like me, there are some pretty odd-ball rules depending where you look. The Turkish I problem is famous, the Unicode dudes had to make an explicit exception for them.
It isn't actually code btw, it's lookup tables. Interesting in itself because it requires MSFT to maintain the /linkres command line option for the C# compiler. A compile option you cannot use in your own projects. It's solely there to get mscorlib to be able to find the .nlp files, the conversion tables for culture rules. Stored in the same subdirectory of the GAC as mscorlib.dll, the effect of the compile option.
But I digress. It stands to reason that StringComparison.OrdinalIgnoreCase is a wee bit quicker than StringComparison.InvariantCultureIgnoreCase. Just because 'invariant' means USA, home of MSFT. Hard to measure, this clocks in at nanoseconds. StringComparison.CurrentCultureIgnoreCase hits those translation tables. Dead slow when you first use it, just slower when you use them later.