[prewett]

I was thinking about it, however I've found that String performance is horrible (at least with Japanese strings) if you do anything like hasSuffix() or hasPrefix(). I think the problem is that String converts to unicode code points as soon as it seems useful, instead of keeping everything in UTF-8 (or whatever, really) and doing memcmp for hasSuffix() and hasPrefix() specifically, which would work much faster. Using NSString everywhere is faster, but then string concatenation involves a bunch of casting.

I'm not much of a server guy, so I might be wrong here, but dealing with strings seems like something a server is likely to need to deal with. Although, maybe the strings are short enough that it's not much of a problem, or maybe strings that are almost always ASCII are fast. Anyway, something to keep in mind.

[bluk]

Were your performance problems before or after Swift 5's switch to using UTF-8 as the preferred encoding? See https://swift.org/blog/utf8-string/ . It sounds like before, so you may want to check out the String performance again.

Swift 5.0 and 5.1 each supposedly made some 10-20% gain in ARC performance compared to the previous version (4.2 and 5.0), so that may also help. I think Swift's performance can be very hit or miss but they (Apple) are making some good strides.

[prewett]

It was Xcode 10.2, I think. (10.something), I think that’s Xcode 5.

hasSuffix() doesn’t need UTF-8 to be performant, though. As long as both strings are both the same encoding, just go back len(suffix) bytes from the end of the string and memcmp to see if they are equal.

[ericlewis]

You can commit a sin and make all strings be NSString