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
