[swift-corelibs-dev] Rules on adding dependencies

[Geordie Jay]

What I’m not so sure about is the most efficient way of working with NSData in this context, considering we are very much assuming the data to have come from a String of some kind (correct me if I’m wrong). So it seems to me like taking NSData insead of just a String is a regression into Objective-C land.




Can anyone explain why we might want to do this rather than working in an idiomatic Swift way (obviously backwards compatibility is a big one – is it the only one?). The only other thing I can think of is that NSData can be streamed. That is going into territory that I haven’t dealt with in Swift yet though. Would love to hear some input from others on this.

On Sat, Dec 5, 2015 at 5:29 PM, Geordie Jay <geojay at gmail.com> wrote:

> I’m not sure about performance hit of calling C from Swift either (it should be statically linked, so I suspect there is none), but the performance is only marginally slower than NSJSONSerialization as is, in the pure Swift version I am making. My test character set is about 2000 characters long, running serialize on it 5000 times, my current Swift-only version takes 1 second for each test run, and the existing (C-backed) NSJSONSerialization takes about 0.75 seconds.
> The difference isn’t huge and I suspect with more optimisation of the Swift code and of the standard library (in particular comparing UTF16 strings) this gap would disappear. I for one would be in favour of a pure Swift solution for readability, and also as a challenge to improve the standard library’s performance.
> Another thing to note is that Swift is supposed to be future-proofed in terms of UTF String handling (I’m not sure about JSON though, to be honest – is it supposed to support CharSets beyond UTF8?), maybe having the strings decode in UTF16 by default is not such a bad idea, even if it has a minor performance hit for now.
> On Sat, Dec 5, 2015 at 5:17 PM, Tom Leavy <tom at wickr.com> wrote:
>> I would rather go right to the end game here and just work on coding up an implementation of JSON encoding / decoding and making it conform to the NSJSONSerialization spec. I can set up a repo for us to work on it.
>> The main decision here, is do we code a small lib in C and then call it from the Swift side, or do we just write the entire implementation in Swift? From a performance standpoint C is usually my go to, but if we use swift with only structs and we really focus on minimizing use of functions that would be costly / do a lot of profiling and optimization we can get very close to equivalent performance? At least to the level of the current objective c / c version? I'm also not sure of potential performance penalties of calling C functions from swift. Someone with more knowledge will have to weigh in on that one.
>> Thomas Leavy | Wickr Inc.
>> VP Mobile Applications & Architecture | Newark, NJ<x-apple-data-detectors://0/1>
>> On Dec 4, 2015, at 6:24 PM, swizzlr <me at swizzlr.co<mailto:me at swizzlr.co>> wrote:
>> Re: Rules on adding dependencies
>> This e-mail message is intended only for the named recipient(s) above and is covered by the Electronic Communications Privacy Act 18 U.S.C. Section 2510-2521. This e-mail is confidential and may contain information that is privileged or exempt from disclosure under applicable law. If you have received this message in error please immediately notify the sender by return e-mail and delete this e-mail message from your computer, mobile devices and any cloud storage backup systems as well as destroy any printed copy you might have made.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151205/232b0767/attachment-0001.html>