[swift-corelibs-dev] Rules on adding dependencies

[Tony Parker]

Hi Geordie,

The choice of NSData instead of String was very deliberate for NSJSONSerialization. The reason is that JSON is received from disk or the network as a data blob, not a String. Converting it into a String requires figuring out the encoding and doing a conversion. NSJSONSerialization looks at the leading bytes and then parses the data directly instead of converting the entire thing to a String first. This is a major perf boost, since there is usually a huge portion of the data which never needs to be a string (numbers, for example). Only actual result Strings need the conversion.

On a higher-level note, I agree with the approach of implementing the existing API first before considering alternate APIs. There is no doubt that dealing with untyped JSON output in Swift results in a less than ideal experience of casts or other things. I want to think about how to improve it, but first I want to make sure we have our cross-platform story in place. This means that clients of Foundation can simply use the same NSJSONSerialization API that they are used to and get the results that they expect.

- Tony

> On Dec 5, 2015, at 8:58 AM, Geordie Jay <geojay at gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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. 
> 
> 
>  _______________________________________________
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151205/cd6db942/attachment-0001.html>