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 <geo...@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 <geo...@gmail.com > <mailto:geo...@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 <t...@wickr.com > <mailto:t...@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 <m...@swizzlr.co > <mailto:m...@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@swift.org <mailto:swift-corelibs-dev@swift.org> > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev > <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
