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

Jump to bottom

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

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

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

palimondo mannequin opened this issue Jul 4, 2019 · 2 comments
Assignees
@Catfish-Man
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. performance standard library Area: Standard library umbrella

Comments

@palimondo
Copy link
Mannequin

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

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?

@Catfish-Man
Copy link
Member

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
Assignees

@Catfish-Man Catfish-Man

Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. performance standard library Area: Standard library umbrella
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Catfish-Man