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-11558] Casting a bridged Array of Strings back to String should hit more fast paths #53963

Open
Catfish-Man opened this issue Oct 2, 2019 · 1 comment
Open

[SR-11558] Casting a bridged Array of Strings back to String should hit more fast paths #53963

Catfish-Man opened this issue Oct 2, 2019 · 1 comment
Labels
improvement standard library Area: Standard library umbrella

Comments

@Catfish-Man
Copy link
Member

Previous ID SR-11558
Radar rdar://problem/55987390
Original Reporter @Catfish-Man
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Improvement
Assignee None
Priority Medium

md5: f676672cf7cc42fa043b21807d572193

Issue Description:

If you profile this code:

let x:NSArray = "Hello world! Hello world! Hello world!".withCString {
  [String(cString: $0), String(cString: $0), String(cString: $0), String(cString: $0), String(cString: $0)]
}
while true {
  _ = x as! [String]
}

You'll see a decent chunk of time spent in

specialized _ArrayBuffer._getElementSlowPath(_:)

which definitely seems like it should be avoidable (that calls objectAtIndex🙂.

I also wonder if there's more we could do to take advantage of the fact that the "NSStrings" in the NSArray are all in fact Swift.__StringStorage.

If you change the example code to

let x = "Hello world! Hello world! Hello world!".withCString {
  [String(cString: $0), String(cString: $0), String(cString: $0), String(cString: $0), String(cString: $0)]
}
let y = x as NSArray 
while true {
  _ = y as! [String]
}

The profile looks even stranger, because we still go down the _getElementSlowPath path, but now that calls back into Swift like this:

+ ! : | 590 specialized _arrayForceCast<A, B>(_:) (in libswiftFoundation.dylib) + 587 [0x7fff6539cd1b]
 + ! : | + 453 specialized _ArrayBuffer._getElementSlowPath(_:) (in libswiftFoundation.dylib) + 70 [0x7fff65401c16]
 + ! : | + ! 441 _CocoaArrayWrapper.subscript.getter (in libswiftCore.dylib) + 25 [0x7fff64ccc7c9]
 + ! : | + ! : 328 @objc __SwiftNativeNSArrayWithContiguousStorage.objectAtSubscript(_:) (in libswiftCore.dylib) + 76 [0x7fff64e4a95c]
 + ! : | + ! : | 231 __ContiguousArrayStorageBase.withUnsafeBufferOfObjects<A>(_:) (in libswiftCore.dylib) + 109 [0x7fff64d153dd]
 + ! : | + ! : | + 102 _ContiguousArrayStorage._withVerbatimBridgedUnsafeBuffer<A>(_:) (in libswiftCore.dylib) + 175 [0x7fff64d155bf]
 + ! : | + ! : | + ! 99 partial apply for thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<Swift.AnyObject>) -> (@owned Swift.AnyObject, @error @owned Error) (in libswiftCore.dylib) + 9 [0x7fff64fa0349]
 + ! : | + ! : | + ! : 93 partial apply for thunk for @callee_guaranteed (@unowned UnsafeBufferPointer<Swift.AnyObject>) -> (@unowned Int, @error @owned Error) (in libswiftCore.dylib) + 20 [0x7fff64f95cd4]
 + ! : | + ! : | + ! : | 46 -[__NSCFString retain] (in CoreFoundation) + 14 [0x7fff2df8eb61]
 + ! : | + ! : | + ! : | + 42 _CFRetain (in CoreFoundation) + 68,17,... [0x7fff2e0819b5,0x7fff2e081982,...]
@Catfish-Man
Copy link
Member Author

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
improvement standard library Area: Standard library umbrella
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Catfish-Man