You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that String's native storage is UTF-8, ending up with strings backed by UTF-16 storage can be more of a performance penalty (in particular, code that is optimizing for speed is now going to be optimized around a UTF-8 representation instead of a UTF-16 representation). As such, we should try to reduce the amount of UTF-16–backed strings we work with in general.
Unfortunately, a lot of core String functionality is provided by the Foundation overlay, and these methods all end up bridging to NSString in order to invoke the existing Foundation methods. Not only does this incur the bridging cost when going to Obj-C, but any strings created from these methods will be backed by NSString and thus will be UTF-16 if not ASCII.
I recognize that a number of these methods have complex behavior that would be a lot of effort to reproduce (in particular, anything that relies on the locale), but there's also basic methods that we could easily reimplement ourselves, such as components(separatedBy:).
As a trivial example, the following returns a UTF-16–backed string:
"héllo world".components(separatedBy: " ")[0]
The text was updated successfully, but these errors were encountered:
Additional Detail from JIRA
md5: 523fca5765ccad40e49e24dfab888b49
Issue Description:
Now that
String
's native storage is UTF-8, ending up with strings backed by UTF-16 storage can be more of a performance penalty (in particular, code that is optimizing for speed is now going to be optimized around a UTF-8 representation instead of a UTF-16 representation). As such, we should try to reduce the amount of UTF-16–backed strings we work with in general.Unfortunately, a lot of core
String
functionality is provided by the Foundation overlay, and these methods all end up bridging toNSString
in order to invoke the existing Foundation methods. Not only does this incur the bridging cost when going to Obj-C, but any strings created from these methods will be backed byNSString
and thus will be UTF-16 if not ASCII.I recognize that a number of these methods have complex behavior that would be a lot of effort to reproduce (in particular, anything that relies on the locale), but there's also basic methods that we could easily reimplement ourselves, such as
components(separatedBy:)
.As a trivial example, the following returns a UTF-16–backed string:
The text was updated successfully, but these errors were encountered: