List of performance regressions caused by switching to ICU

[adamsitnik]

Before 5.0, we were using ICU only on Unix systems. In 5.0 we have decided to use it on Windows by default as well.

This is something that we have done in order to have the same behavior of string-related globalization APIs on every OS.

However, this particular change has affected the performance characteristics of many frequently used methods. Some of them have regressed, some have improved.

Recently we have reported a lot of 5.0 regressions related to that. Since we have done this on purpose and we are most probably not going to revert the switch, I am opening this issue to track the list of all known regressions. When the list becomes complete, we are most probably going to update the 5.0 release docs and close the issue and label it as wont fix.

Please feel free to edit the list.

Known changes:

• System.Memory.ReadOnlySpan.IndexOfString 5 regressions, 5 improvements
• System.Globalization.Tests.StringHash 2 regressions, 4 improvements
• System.Globalization.Tests.StringEquality: 8 regressions, 14 improvements
• System.Globalization.Tests.StringSearch: 30 regressions, 32 improvements
• System.Globalization.Tests.Perf_DateTimeCultureInfo.Parse: 1 regression, 5 improvements

cc @danmosemsft @tarekgh @billwert @DrewScoggins @GrabYourPitchforks @jkotas @safern

Tagging subscribers to this area: @tarekgh, @safern, @krwq
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

System.Memory.ReadOnlySpan.IndexOfString 5 regressions, 5 improvements

Method	input	value	comparisonType	3.1 Mean	5.0 ICU	5.0 NLS
IndexOfString	AAAAA5AAAA	5	InvariantCulture	79.07 ns	35.41 ns	72.05 ns
IndexOfString	AAAAAAAAAAAA(...)AAAAAAAAAAAA [1000]	X	Ordinal	39.72 ns	38.89 ns	38.25 ns
IndexOfString	AAAAAAAAAAAA(...)AAAAAAAAAAAA [100]	x	InvariantCultureIgnoreCase	300.45 ns	214.39 ns	294.59 ns
IndexOfString	AAAAAAAAAAAA(...)AAAAAAAAAAAA [100]	x	OrdinalIgnoreCase	245.94 ns	802.33 ns	240.42 ns
IndexOfString	ABCDE	c	InvariantCultureIgnoreCase	71.81 ns	30.26 ns	63.83 ns
IndexOfString	Hello Worldb(...)allylong!xyz [186]	w	OrdinalIgnoreCase	45.80 ns	102.63 ns	40.30 ns
IndexOfString	Hello Worldb(...)allylong!xyz [187]	~	Ordinal	28.52 ns	22.28 ns	21.03 ns
IndexOfString	Hello Worldbb(...)bbbbbbbbbbba! [47]	y	Ordinal	24.15 ns	14.09 ns	13.57 ns
IndexOfString	More Test's	Tests	OrdinalIgnoreCase	56.38 ns	108.93 ns	50.48 ns
IndexOfString	StrIng	string	OrdinalIgnoreCase	38.79 ns	55.01 ns	33.86 ns
IndexOfString	foobardzsdzs	rddzs	InvariantCulture	101.46 ns	44.93 ns	94.90 ns
IndexOfString	string1	string2	InvariantCulture	91.45 ns	37.14 ns	80.95 ns
IndexOfString	?	?	InvariantCulture	108.70 ns	4,069.11 ns	105.36 ns
IndexOfString	????????????(...)???????????? [100]	?	Ordinal	25.08 ns	16.88 ns	15.48 ns
IndexOfString	????????????(...)???????????? [1000]	x	Ordinal	39.70 ns	39.19 ns	37.99 ns

Comment: InvariantCulture and InvariantCultureIgnoreCase have improved, while OrdinalIgnoreCase has regressed. We could implement OrdinalIgnoreCase path in managed code if it ever becomes a problem

[danmoseley]

Thank you @adamsitnik good idea I'm glad you created this.

[tarekgh]

I have this PR opened for addressing all ordinal operations #40910

[tarekgh]

@adamsitnik are you going to close all other bugs complaining about ICU perf against this one?

[adamsitnik]

are you going to close all other bugs complaining about ICU perf against this one?

That's my plan. I will try to do my best to do it for as many as I can.

[tarekgh]

Also, I want to be clear about the expectation here. I don't think we can fix all perf here as we are limited by calling ICU. we can look at how we can improve it but I am not expecting to get the perf to the point where we used to call NLS. So, it will be good to decide which items in this list is a blocker. The only one was the Ordinal cases which I am addressing in the attached PR. I am not aware of any other blocking scenario. We'll look more of course on other scenarios anyway but I am not sure how much we can do before 5.0 release.