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> 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> 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
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
