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?
to your account
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*)
The text was updated successfully, but these errors were encountered:
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?
Sorry, something went wrong.
Fixed in #26007
No branches or pull requests