Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

palimondo mannequin opened this issue Jul 4, 2019 · 2 comments

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

palimondo mannequin opened this issue Jul 4, 2019 · 2 comments


Copy link

@palimondo palimondo mannequin commented Jul 4, 2019

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*)
Copy link

@milseman milseman mannequin commented Jul 5, 2019

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?

Copy link

@Catfish-Man Catfish-Man commented Jul 14, 2019

Fixed in #26007

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant