<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Apr 22, 2016, at 8:48 PM, Charles Srstka via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><blockquote type="cite" class="">On Apr 22, 2016, at 5:05 PM, Greg Parker &lt;<a href="mailto:gparker@apple.com" class="">gparker@apple.com</a>&gt; wrote:</blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">On Apr 22, 2016, at 2:36 PM, Charles Srstka via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">One comment:<br class=""><br class="">"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).”<br class=""><br class="">Would it not be more efficient to bridge to the C-based CFData and CFMutableData implementations instead, to avoid the object overhead?</div></div></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div><div class="">Not necessarily. Foundation often has less overhead than CF nowadays.</div></div></div></blockquote></div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">Charles</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>&nbsp; &nbsp; David</div><br><blockquote type="cite"><div><div class=""><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>