{"id":24403,"date":"2019-02-22T16:18:45","date_gmt":"2019-02-22T21:18:45","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=24403"},"modified":"2019-03-06T08:58:07","modified_gmt":"2019-03-06T13:58:07","slug":"swift-subclass-of-nstextstorage-is-slow-because-of-swift-bridging","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/02\/22\/swift-subclass-of-nstextstorage-is-slow-because-of-swift-bridging\/","title":{"rendered":"Swift Subclass of NSTextStorage Is Slow Because of Swift Bridging"},"content":{"rendered":"

Darren Mo<\/a> (via Marcin Krzyzanowski<\/a>):<\/p>\n

Calling -[NSTextStorage attributesAtIndex:effectiveRange:]<\/code> is nearly 3 times as slow for TextStorageSwiftSubclass<\/code> compared to NSTextStorage<\/code>. Time profiling shows that this is caused by the bridging of the Objective-C dictionary return value to Swift. Effectively, this means we cannot use Swift if we want to subclass NSTextStorage<\/code>.<\/p><\/blockquote>\n

There are ways to get around bridging overhead at method call sites. I think the issue here is that these techniques can’t be applied because the subclass is being called by the frameworks. Perhaps there’s a way to work around it by implementing certain methods in Objective-C and others in a Swift extension, but interoperability can be messy depending on how much you are taking advantage of Swift’s features.<\/p>\n\n

Jonas Boberg<\/a>:<\/p>\n

Note that this is not just an issue with subclasses, but also delegate methods, such as NSLayoutManagerDelegate<\/code> shouldUseTemporaryAttributes<\/code>.<\/p><\/blockquote>\n\n

Previously:<\/p>\n