Erik, do you think someone can help me find an alternative? We probably don't need all of the machinery of dynamic casts etc. This could just be a load of the meta type and pointer compare, but I couldn't get any alternatives to stick when I tried a month ago.

(probably just silly ignorance of the right method on my part).

Here's the relevant code:

@_versioned
@inline(never) // Hide the CF dependency
internal
func _makeCocoaStringGuts(_ cocoaString: _CocoaString) -> _StringGuts {
  if let ascii = cocoaString as? _ASCIIStringStorage {
    return _StringGuts(ascii)
  } else if let utf16 = cocoaString as? _UTF16StringStorage {
    return _StringGuts(utf16)
  } else if let wrapped = cocoaString as? _NSContiguousString {
    return wrapped._guts
  } else if _isObjCTaggedPointer(cocoaString) {
    return _StringGuts(_taggedCocoaObject: cocoaString)
  }

_ASCIIStringStorage / _UTF16StringStorage are type aliases of a generic type:

internal typealias _ASCIIStringStorage = _SwiftStringStorage<UInt8>
internal typealias _UTF16StringStorage = _SwiftStringStorage<UTF16.CodeUnit>

Inside the disassembly, I see calls to getGenericMetadata and dynamicCastClass. Are we not statically producing meta types for those two? Can I force us to, or should I de-generic it? It's only generic for 1-byte vs 2-byte storage, and we could always duplicate code if we must.

CC @belkadan @gottesmm in case it's a resilience thing, and if there's a way around this

@swift-ci create

I don't think that's a resilience thing, though I'm not 100% sure. I don't think generic types get statically instantiated, ever.

You could avoid dynamicCastClass by using type(of: cocoaString) == _ASCIIStringStorage, which defines away subclasses. (And then do unsafeDowncast to avoid checking again once you've done that.)

I'm trying that in #14148 it helps a tiny bit.

Joe S., I looked into this further and there's definitely an extra retain/release pair inside makeCocoaStringGuts that's contributing here. I attached the disassembled CFG. There you can see CFCocoaStringCreateCopy creates a +1 reference and stores it in r14 (this is "immutableCopy" in the source). We bundle it up in a bridgeObject, which retains it again. Then, we release r14.

Also notice that there's a constant folding opportunity here: loc_31878a's basic block calls retain on a known-value. Eliminating this makes the analysis simpler: the _swift_unknownRelease should be moved into loc_31878a, and the bridgeObject retain in loc_318775 is eliminated.

That was harder to explain in prose than I thought. Attached a version with red lines through what should be eliminated and a green arrow for the move.