[swift-evolution] Mutability for Foundation types in Swift

[David Smith]

> On Apr 22, 2016, at 8:48 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> 
>>> On Apr 22, 2016, at 5:05 PM, Greg Parker <gparker at apple.com> wrote:
>>> 
>>> On Apr 22, 2016, at 2:36 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> One comment:
>>> 
>>> "In the most common case where a developer does not provide a custom reference type, then the backing store is our existing NSData and NSMutableData implementations. This consolidates logic into one place and provides cheap bridging in many cases (see Bridging for more information).”
>>> 
>>> Would it not be more efficient to bridge to the C-based CFData and CFMutableData implementations instead, to avoid the object overhead?
>> 
>> Not necessarily. Foundation often has less overhead than CF nowadays.
> 
> That’s interesting; I hadn’t known that. What causes that? My understanding had always been that the NS and CF objects, being toll-free bridged to each other, shared the same default implementations, with the only difference being that the NS versions involved the overhead from objc_msgSend() as well as, in many cases, an autorelease.
> 
> Charles

There's a wide variety of bridging techniques in use, but in NSData's case the implementations are separate (and there are 5 implementations for NSData, 1 for CFData). CFData also has to pay the cost for detecting whether it's argument is a bridged NSData, which is ironically about as expensive as a message send.

    David

> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160422/378c2429/attachment.html>