[SR-11069] Slow case conversion of a longer ASCII String

[palimondo]

Previous ID	SR-11069
Radar	None
Original Reporter	@palimondo
Type	Bug
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Standard Library
Labels	Bug, Performance
Assignee	@Catfish-Man
Priority	Medium

md5: f06094738f2575f27454c6223b3d888a

Issue Description:

The case conversions: uppercased() and lowercased() on longer string (6kB) are suspiciously slower if the string is composed of only ASCII characters.

See new benchmarks: AngryPhonebook.ASCII vs. AngryPhonebook.Strasse from PR #25309 .

Non-ASCII string goes through ICU that incurs also UTF-8 -> UTF-16 transcoding but is still about 3-4x faster than the ASCII string case conversion.

Profiling these benchmarks in Instruments reveals that the heaviest stacktrace in the non-ASCII case of AngryPhonebook.Strasse looks like this:

   6 Benchmark_O 1412.0  largeAngryPhonebook(_:_:)
   5 libswiftCore.dylib 827.0  specialized String.uppercased()
   4 libicucore.A.dylib 393.0  u_strToUpper
   3 libicucore.A.dylib 393.0  0x7fff74cbdd6f
   2 libicucore.A.dylib 392.0  0x7fff74cbd796
   1 libicucore.A.dylib 40.0  u_memcpy
   0 libsystem_platform.dylib 21.0  _platform_memmove$VARIANT$Base

while the AngryPhonebook.ASCII looks like this:

   4 Benchmark_O 3976.0  largeAngryPhonebook(_:_:)
   3 libswiftCore.dylib 2002.0  specialized String.uppercased()
   2 libswiftCore.dylib 1483.0  _StringGuts.append(_:)
   1 libswiftCore.dylib 450.0  swift_bridgeObjectRetain
   0 libswiftCore.dylib 266.0  _swift_retain_(swift::HeapObject*)

[milseman]

Seems like all this overhead would be eliminated by the initializer with uninitialized capacity that @Catfish-Man has a proposal for. David, want to try it out as purely internal and see the benefits here first?

[Catfish-Man]

Fixed in #26007